elasticSearch
match查询，匹配查询是全文搜索的一种查询。
match_phrase查询是短文匹配查询，他会把需要匹配的内容不进行修改直接当做一个term来查询。
高亮搜索：在更节点上面有一个关键词hightlight,可以高亮我们的搜索结果。当执行该查询时，返回结果与之前一样，与此同时结果中还多了一个叫做 highlight 的部分。这个部分包含了 about 属性匹配的文本片段，并以 HTML 标签 封装：
GET /megacorp/employee/_search
{
"query" : {
"match_phrase" : {
"about" : "rock climbing"
}
},
"highlight": {
"fields" : {
"about" : {}
}
}
}
集群的健康
GET /_cluster/health
在其中我们只关心status字段他有三种状态
green/yellow/red
green
所有的主分片和副本分片都正常运行。
yellow
所有的主分片都正常运行，但不是所有的副本分片都正常运行。
red
有主分片没能正常运行。
{
"cluster_name": "elasticsearch",
"status": "green",
"timed_out": false,
"number_of_nodes": 2,
"number_of_data_nodes": 2,
"active_primary_shards": 3,
"active_shards": 6,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0,
"delayed_unassigned_shards": 0,
"number_of_pending_tasks": 0,
"number_of_in_flight_fetch": 0,
"task_max_waiting_in_queue_millis": 0,
"active_shards_percent_as_number": 100
}
number_of_nodes:节点的个数
number_of_data_nodes：数据节点个个数
创建一个索引
索引采用的是默认的配置，新的字段通过动态映射的方式被添加到类型映射。现在我们需要对这个建立索引的过程做更多的控制：我们想要确保这个索引有数量适中的主分片，并且在我们索引任何数据 之前 ，分析器和映射已经被建立好。
为了达到这个目的，我们需要手动创建索引，在请求体里面传入设置或类型映射，如下所示：
PUT /my_index
{
"settings": { ... any settings ... },
"mappings": {
"type_one": { ... any mappings ... },
"type_two": { ... any mappings ... },
...
}
}
索引设置
下面是两个 最重要的设置：
- number_of_shards 每个索引的主分片数，默认值是 5 。这个配置在索引创建后不能修改。
- number_of_replicas 每个主分片的副本数，默认值是 1 。对于活动的索引库，这个配置可以随时修改。
例如，我们可以创建只有 一个主分片，没有副本的小索引：
PUT /my_temp_index
{
"settings": {
"number_of_shards" : 1,
"number_of_replicas" : 0
}
}
然后，我们可以用 update-index-settings API 动态修改副本数：
PUT /my_temp_index/_settings
{
"number_of_replicas": 1
}
检查文档是否存在
如果只想检查一个文档是否存在 –根本不想关心内容–那么用 HEAD 方法来代替 GET 方法。 HEAD 请求没有返回体，只返回一个 HTTP 请求报头
curl -i -XHEAD http://localhost:9200/website/blog/123
当返回200时表示存在
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
当返回404表示不存在
查看匹配过程
GET /_validate/query?explain
{
"query": {
"multi_match": {
"query": "Poland Street W1V",
"type": "most_fields",
"fields": [ "street", "city", "country", "postcode" ]
}
}
}
(street:poland street:street street:w1v)
(city:poland city:street city:w1v)
(country:poland country:street country:w1v)
(postcode:poland postcode:street postcode:w1v)
更新一个文档
在es中文档是不可改变的，不能修改他们。相反，如果想要更新现有的文档，需要 重建索引 或者进行替换。
如果使用put修改一个文档，那么ES实际是这么做的：
1. 从旧文档中构建json
2. 更改json
3. 删除旧文档
4. 索引一个新文档
部分更新
我们已经介绍过 更新一个文档的方法是检索并修改它，然后重新索引整个文档，这的确如此。然而，使用 update API 我们还可以部分更新文档，例如在某个请求时对计数器进行累加 。
我们在一个文档的某个位置进行部分更新。然而在内部， update API 简单使用与之前描述相同的 检索-修改-重建索引 的处理过程。 区别在于这个过程发生在分片内部，这样就避免了多次请求的网络开销。通过减少检索和重建索引步骤之间的时间，我们也减少了其他进程的变更带来冲突的可能性。
update 请求最简单的一种形式是接收文档的一部分作为 doc 的参数， 它只是与现有的文档进行合并。对象被合并到一起，覆盖现有的字段，增加新的字段。 例如，我们增加字段 tags 和 views 到我们的博客文章，如下所示：
POST /website/blog/1/_update
{
"doc" : {
"tags" : [ "testing" ],
"views": 0
}
}
如果请求成功，我们看到类似于 index 请求的响应
{
"_index" : "website",
"_id" : "1",
"_type" : "blog",
"_version" : 3
}
检索文档显示了更新后的 _source 字段：
{
"_index": "website",
"_type": "blog",
"_id": "1",
"_version": 3,
"found": true,
"_source": {
"title": "My first blog entry",
"text": "Starting to get the hang of this...",
"tags": [ "testing" ],
"views": 0
}
}
脚本可以在 update API中用来改变 _source 的字段内容， 它在更新脚本中称为 ctx._source 。 例如，我们可以使用脚本来增加博客文章中 views 的数量：
POST /website/blog/1/_update
{
"script" : "ctx._source.views+=1"
}
删除一个文档
DELETE /website/blog/123
分页
和 SQL 使用 LIMIT 关键字返回单个 page 结果的方法相同，Elasticsearch 接受 from 和 size 参数：
size :显示应该返回的结果数量，默认是10
form ：显示应该逃过的初始结果数量，默认是0
ES分页有问题：
理解为什么深度分页是有问题的，我们可以假设在一个有 5 个主分片的索引中搜索。 当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给 协调节点 ，协调节点对 50 个结果排序得到全部结果的前 10 个。
现在假设我们请求第 1000 页–结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。 然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。
可以看到，在分布式系统中，对结果排序的成本随分页的深度成指数上升。这就是 web 搜索引擎对任何查询都不要返回超过 1000 个结果的原因。
查看一个类型的映射定义
GET /gb/_mapping/tweet
得到的结果如下
{
"gb": {
"mappings": {
"tweet": {
"properties": {
"date": {
"type": "date",
"format": "strict_date_optional_time||epoch_millis"
},
"name": {
"type": "string"
},
"tweet": {
"type": "string"
},
"user_id": {
"type": "long"
}
}
}
}
}
}
自定义映射
尽管在很多情况下基本域数据类型 已经够用，但你经常需要为单独域自定义映射 ，特别是字符串域。自定义映射允许你执行下面的操作
- 全文字符串域和精确值字符串域的区别
- 使用特定语言分析器
- 优化域以适应部分匹配
- 指定自定义数据格式
- 等等
域最重要的属性是 type 。对于不是 string 的域，你一般只需要设置 type
{
"number_of_clicks": {
"type": "integer"
}
}
默认， string 类型域会被认为包含全文。就是说，它们的值在索引前，会通过 一个分析器，针对于这个域的查询在搜索前也会经过一个分析器。
而对于string 域映射的两个最重要 属性是 index 和 analyzer 。
index 属性控制怎样索引字符串。它可以是下面三个值
- analyzed 首先分析字符串，然后索引它。换句话说，以全文索引这个域。
- not_analyzed 索引这个域，所以可以搜索到它，但索引指定的精确值。不对它进行分析。
- no Don’t index this field at all不索引这个域。这个域不会被搜索到。
string 域 index 属性默认是 analyzed 。如果我们想映射这个字段为一个精确值，我们需要设置它为 not_analyzed ：
{
"tag": {
"type": "string",
"index": "not_analyzed"
}
}
analyzer
对于 analyzed 字符串域，用 analyzer 属性指定在搜索和索引时使用的分析器。默认， Elasticsearch 使用 standard 分析器， 但你可以指定一个内置的分析器替代它
{
"tweet": {
"type": "string",
"analyzer": "ik_max_word",//创建索引时的分析器
"search_analyzer": "ik_max_word"//搜索是用的分析器
}
}
更新映射
当你首次 创建一个索引的时候，可以指定类型的映射。你也可以使用 /_mapping 为新类型（或者为存在的类型更新映射）增加映射。
尽管你可以 增加_ 一个存在的映射，你不能 _修改 存在的域映射。如果一个域的映射已经存在，那么该域的数据可能已经被索引。如果你意图修改这个域的映射，索引的数据可能会出错，不能被正常的搜索。
我们可以更新一个映射来添加一个新域，但不能将一个存在的域从 analyzed 改为 not_analyzed 。
创建一个新索引，指定 tweet 域使用 english 分析器
PUT /gb
{
"mappings": {
"tweet" : { //类型
"properties" : { //类型的属性列表
"tweet" : { //具体的属性
"type" : "string",
"analyzer": "english"
},
"date" : {
"type" : "date"
},
"name" : {
"type" : "string"
},
"user_id" : {
"type" : "long"
}
}
}
}
}
稍后，我们决定在 tweet 映射增加一个新的名为 tag 的 not_analyzed 的文本域，使用 _mapping
PUT /gb/_mapping/tweet
{
"properties" : {
"tag" : {
"type" : "string",
"index": "not_analyzed"
}
}
}
注意，我们不需要再次列出所有已存在的域，因为无论如何我们都无法改变它们。新域已经被合并到存在的映射中。
测试
GET /gb/_analyze
{
"field": "tweet",
"text": "Black-cats"
}
------------结果--------------
{
"tokens": [
{
"token": "black",
"start_offset": 0,
"end_offset": 5,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "cat",
"start_offset": 6,
"end_offset": 10,
"type": "<ALPHANUM>",
"position": 1
}
]
}
GET /gb/_analyze
{
"field": "tag",
"text": "Black-cats"
}
------------结果-------------
{
"tokens": [
{
"token": "Black-cats",
"start_offset": 0,
"end_offset": 10,
"type": "word",
"position": 0
}
]
}
复杂类型的映射–对象的映射
1.多值域
很有可能，我们希望 tag 域 包含多个标签。我们可以以数组的形式索引标签：
{ "tag": [ "search", "nosql" ]}
对于数组，没有特殊的映射需求。任何域都可以包含0、1或者多个值，就像全文域分析得到多个词条。
这暗示 数组中所有的值必须是相同数据类型的 。你不能将日期和字符串混在一起。如果你通过索引数组来创建新的域，Elasticsearch 会用数组中第一个值的数据类型作为这个域的 类型 。
2.空域
当然，数组可以为空。 这相当于存在零值。 事实上，在 Lucene 中是不能存储 null 值的，所以我们认为存在 null 值的域为空域。
下面三种域被认为是空的，它们将不会被索引：
"null_value": null,
"empty_array": [],
"array_with_null_value": [ null ]
3.多层级对象
{
"tweet": "Elasticsearch is very flexible",
"user": {
"id": "@johnsmith",
"gender": "male",
"age": 26,
"name": {
"full": "John Smith",
"first": "John",
"last": "Smith"
}
}
}
Elasticsearch 会动态 监测新的对象域并映射它们为 对象 ，在 properties 属性下列出内部域：
{
"gb": {
"tweet": {
"properties": {
"tweet": { "type": "string" },
"user": {
"type": "object",
"properties": {
"id": { "type": "string" },
"gender": { "type": "string" },
"age": { "type": "long" },
"name": {
"type": "object",
"properties": {
"full": { "type": "string" },
"first": { "type": "string" },
"last": { "type": "string" }
}
}
}
}
}
}
}
}
Lucene 不理解内部对象。 Lucene 文档是由一组键值对列表组成的。为了能让 Elasticsearch 有效地索引内部类，它把我们的文档转化成这样：
{
"tweet": [elasticsearch, flexible, very],
"user.id": [@johnsmith],
"user.gender": [male],
"user.age": [26],
"user.name.full": [john, smith],
"user.name.first": [john],
"user.name.last": [smith]
}
4.内部对象数组
最后，考虑包含 内部对象的数组是如何被索引的。 假设我们有个 followers 数组：
{
"followers": [
{ "age": 35, "name": "Mary White"},
{ "age": 26, "name": "Alex Jones"},
{ "age": 19, "name": "Lisa Smith"}
]
}
这个文档会像我们之前描述的那样被扁平化处理，结果如下所示：
{
"followers.age": [19, 26, 35],
"followers.name": [alex, jones, lisa, smith, mary, white]
}
{age: 35} 和 {name: Mary White} 之间的相关性已经丢失了，因为每个多值域只是一包无序的值，而不是有序数组。
查看一个分词器的使用
GET /_analyze
{
"analyzer": "ik_smart",
"text": "中国驻洛杉矶领事馆遭亚裔男子枪击"
}
几种重要查询
match_all
查询简单的 匹配所有文档。在没有指定查询方式时，它是默认的查询。
它经常与 filter 结合使用–例如，检索收件箱里的所有邮件。所有邮件被认为具有相同的相关性，所以都将获得分值为 1 的中性 _score。
match
无论你在任何字段上进行的是全文搜索还是精确查询，match 查询是你可用的标准查询。
不管是在哪里使用都可以，如果你在一个全文字段上使用 match 查询，在执行查询前，它将用正确的分析器去分析查询字符串。
{ "match": { "tweet": "About Search" }}
match查询的步骤是：
1. 检查字段类型 。 标题 title 字段是一个 string 类型（ analyzed ）已分析的全文字段，这意味着查询字符串本身也应该被分析。
2. 分析查询字符串 。将查询的字符串 About Search! 传入标准分析器中，输出的结果是两个项 about bearch 。match 查询执行的是单个底层 term 查询。类型是or，匹配其中一个就算命中。
3. 查找匹配文档
4. 为每个文档评分 。用 term 查询计算每个文档相关度评分 _score ，这是种将 词频（词在这个文档中出现的频率越大分越高）和反向文档频率（inverse document frequency，即词在所有文档的这个字段中出现的频率，越高分越低），以及字段的长度（即字段越短相关度越高）相结合的计算方式。
operator
match匹配多次默认使用的operator 参数是or。即出现一个词就算命中。可以将operator改成and,即需要匹配所有与的词才算是命中。
minimum_should_match ：所有与任意 间二选一有点过于非黑即白，不太好，所以match还支持minimum_should_match 最小匹配参数，它来控制匹配的词的个数到达多少个才算是命中。
它可以接受数字，但是更加常用的是接受百分比。在之前三词项的示例中， 75% 会自动被截断成 66.6% ，即三个里面两个词。无论这个值设置成什么，至少包含一个词项的文档才会被认为是匹配的。
如果在一个精确值的字段上使用它， 例如数字、日期、布尔或者一个 not_analyzed 字符串字段，那么它将会精确匹配给定的值,底层会直接使用term查询。而对于需要匹配的就会先经过分析器生成词条，然后使用term
{ "match": { "age":26 }}
{ "match": { "date": "2014-09-01" }}
{ "match": { "public": true }}
{ "match": { "tag":"full_text" }}
multi_match
multi_match 查询可以在多个字段上执行相同的 match 查询：
{
"multi_match": {
"query": "full text search",
"fields": [ "title", "body" ]
}
}
multi_match 多匹配查询的类型有多种，其中的三种
best_fields 最佳字段
most_fields 多数字段
cross_fields 跨字段
phrase 短语匹配
默认情况下，查询的类型是 best_fields ， 这表示它会为每个字段生成一个 match 查询，然后将它们组合到 dis_max(分离 最大化查询将任何与任一查询匹配的文档作为结果返回，但只将最佳匹配的评分作为查询的评分结果返回)查询的内部。
{
"dis_max": {
"queries": [
{
"match": {
"title": {
"query": "Quick brown fox",
"minimum_should_match": "30%"
}
}
},
{
"match": {
"body": {
"query": "Quick brown fox",
"minimum_should_match": "30%"
}
}
},
],
"tie_breaker": 0.3
}
}
以上使用multi_match查询可写成
{
"multi_match": {
"query": "Quick brown fox",
"type": "best_fields",
"fields": [ "title", "body" ],
"tie_breaker": 0.3,
"minimum_should_match": "30%"
}
}
查询字段名称的模糊匹配
字段名称可以以模糊的方式给出：任何与模糊模式正则匹配的字段都会被包括在搜索条件中， 例如可以使用以下方式同时匹配 book_title 、 chapter_title 和 section_title （书名、章名、节名）这三个字段：
{
"multi_match": {
"query": "Quick brown fox",
"fields": "*_title"
}
}
提升权重的方式
可以使用 ^ 字符语法为单个字段提升权重，在字段名称的末尾添加 ^boost ， 其中 boost 是一个浮点数：
{
"multi_match": {
"query": "Quick brown fox",
"fields": [ "*_title", "chapter_title^2" ]
}
}
chapter_title 这个字段的 boost 值为 2 ，而其他两个字段 book_title 和 section_title 字段的默认 boost 值为 1 。
tie_breaker参数
可以通过tie_breaker参数将其他语句的评分也考虑其中。因为mutil_match默认是best_fields。但是我们可能希望最佳字段只是占很大的比重，其他字段有匹配更好，但是也希望如果其他字段匹配了，更是我们想要的。通过tie_breaker就可以实现。
tie_breaker 参数提供了一种 dis_max 和 bool 之间的折中选择，它的评分方式如下：
1. 获得最佳匹配语句的评分 _score 。
2. 将其他匹配语句的评分结果与 tie_breaker 相乘。
3. 对以上评分求和并规范化。
{
"query": {
"dis_max": {
"queries": [
{ "match": { "title": "Quick pets" }},
{ "match": { "body": "Quick pets" }}
]
}
}
}
{
"hits": [
{
"_id": "1",
"_score": 0.12713557,
"_source": {
"title": "Quick brown rabbits",
"body": "Brown rabbits are commonly seen."
}
},
{
"_id": "2",
"_score": 0.12713557,
"_source": {
"title": "Keeping pets healthy",
"body": "My quick brown fox eats rabbits on a regular basis."
}
}
]
}
这二者的评分一样，但是很明显我们想得到的是第二个
使用tie_breaker
most_fields
多数字段的规则是所有匹配字段的评分合并起来。这种type让multi_match 查询用 bool 查询将两个字段语句包在里面。
使用多字段映射对同一个字段使用不同的分词器进行分析
GET /my_index/_search
{
"query": {
"multi_match": {
"query": "jumping rabbits",
"type": "most_fields",
"fields": [ "title^10", "title.std" ]
}
}
}
best_fields和most_fields都是字段中心式
但是most_fields 方式的问题这种方式也存在着一些问题，因为most_fields是字段中心式，而不是词语中心式的
- 它是为多数字段匹配 任意 词设计的，而不是在 所有字段 中找到最匹配的。
- 它不能使用 operator 或 minimum_should_match 参数来降低次相关结果造成的长尾效应。（不能用operator，minimum_should_match）
- 词频对于每个字段是不一样的，而且它们之间的相互影响会导致不好的排序结果。(用在不同字段)
cross-fields跨字段查询
cross-fields是字段中心式的，只要匹配。
cross_fields 使用词中心式（term-centric）的查询方式，这与 best_fields 和 most_fields 使用字段中心式（field-centric）的查询方式非常不同，它将所有字段当成一个大字段，并在 每个字段 中查找 每个词 。
为了说明字段中心式（field-centric）与词中心式（term-centric）这两种查询方式的不同， 先看看以下字段中心式的 most_fields 查询的 explanation 解释：
GET /_validate/query?explain
{
"query": {
"multi_match": {
"query": "peter smith",
"type": "most_fields",
"operator": "and", //所有词语必须出现
"fields": [ "first_name", "last_name" ]
}
}
}
对于匹配的文档， peter 和 smith 都必须同时出现在相同字段中，要么是 first_name 字段，要么 last_name 字段：
(+first_name:peter +first_name:smith)
(+last_name:peter +last_name:smith)
词中心式 会使用以下逻辑：
+(first_name:peter last_name:peter)
+(first_name:smith last_name:smith)
换句话说，词 peter 和 smith 都必须出现，但是可以出现在任意字段中。cross_fields 类型首先分析查询字符串并生成一个词列表，然后它从所有字段中依次搜索每个词。这种不同的搜索方式很自然的解决了 字段中心式 查询三个问题中的二个
剩下的问题是逆向文档频率不同。
幸运的是 cross_fields 类型也能解决这个问题，通过 validate-query 可以看到：
GET /_validate/query?explain
{
"query": {
"multi_match": {
"query": "peter smith",
"type": "cross_fields",
"operator": "and",
"fields": [ "first_name", "last_name" ]
}
}
}
它通过 混合 不同字段逆向索引文档频率的方式解决了词频的问题：
+blended("peter", fields: [first_name, last_name])
+blended("smith", fields: [first_name, last_name])
它会同时在 first_name 和 last_name 两个字段中查找 smith 的 IDF(反向词频) ，然后用两者的最小值作为两个字段的 IDF 。结果实际上就是 smith 会被认为既是个平常的姓，也是平常的名。
pharse
pharse就是将查询的词语当成一个term在不同的字段中查找，通过operator的or或者and来确定得分
range查询
{
"range": {
"age": {
"gte": 20,
"lt": 30
}
}
}
- gt 大于
- gte大于等于
- lt小于
- lte小于等于
如果想要范围无界（比方说 >20 ），只须省略其中一边的限制：
"range" : {
"price" : {
"gt" : 20
}
}
日期范围
range 查询同样可以应用在日期字段上：
"range" : {
"timestamp" : {
"gt" : "2014-01-01 00:00:00",
"lt" : "2014-01-07 00:00:00"
}
}
当使用它处理日期字段时， range 查询支持对 日期计算（date math） 进行操作，比方说，如果我们想查找时间戳在过去一小时内的所有文档：
"range" : {
"timestamp" : {
"gt" : "now-1h"
}
}
这个过滤器会一直查找时间戳在过去一个小时内的所有文档，让过滤器作为一个时间 滑动窗口（sliding window） 来过滤文档。
日期计算还可以被应用到某个具体的时间，并非只能是一个像 now 这样的占位符。只要在某个日期后加上一个双管符号 (||) 并紧跟一个日期数学表达式就能做到：
"range" : {
"timestamp" : {
"gt" : "2014-01-01 00:00:00",
"lt" : "2014-01-01 00:00:00||+1M" //早于 2014 年 1 月 1 日加 1 月（2014 年 2 月 1 日 零时）
}
}
term查询
term 查询被用于精确值 匹配，这些精确值可能是数字、时间、布尔或者那些 not_analyzed 的字符串。
term 查询对于输入的文本不 分析 ，所以它将给定的值进行精确查询。：
{ "term": { "age": 26 }}
{ "term": { "date": "2014-09-01" }}
{ "term": { "public": true }}
{ "term": { "tag": "full_text" }}
terms查询
terms 查询和 term 查询一样，但它允许你指定多值进行匹配。如果这个字段包含了指定值中的任何一个值，那么这个文档满足条件：
{ "terms": { "tag": [ "search", "full_text", "nosql" ] }}
和 term 查询一样，terms 查询对于输入的文本不分析。它查询那些精确匹配的值（包括在大小写、重音、空格等方面的差异）。
一定要了解 term 和 terms 是 包含（contains） 操作，而非 等值（equals） （判断）。
当 term 查询匹配标记 search 时，它直接在倒排索引中找到记录并获取相关的文档 ID，如倒排索引所示，这里文档 1 和文档 2 均包含该标记，所以两个文档会同时作为结果返回。
由于倒排索引表自身的特性，整个字段是否相等会难以计算，如果确定某个特定文档是否 只（only） 包含我们想要查找的词呢？首先我们需要在倒排索引中找到相关的记录并获取文档 ID，然后再扫描 倒排索引中的每行记录 ，查看它们是否包含其他的 terms 。
可以想象，这样不仅低效，而且代价高昂。正因如此， term 和 terms 是 必须包含（must contain） 操作，而不是 必须精确相等（must equal exactly）
精确相等
如果一定期望得到我们前面说的那种行为（即整个字段完全相等），最好的方式是增加并索引另一个字段， 这个字段用以存储该字段包含词项的数量，同样以上面提到的两个文档为例，现在我们包括了一个维护标签数的新字段：
{ "tags" : ["search"], "tag_count" : 1 }
{ "tags" : ["search", "open_source"], "tag_count" : 2 }
一旦增加这个用来索引项 term 数目信息的字段，我们就可以构造一个 constant_score 查询，来确保结果中的文档所包含的词项数量与要求是一致的：
GET /my_index/my_type/_search
{
"query": {
"constant_score" : {
"filter" : {
"bool" : {
"must" : [
{ "term" : { "tags" : "search" } },
{ "term" : { "tag_count" : 1 } }
]
}
}
}
}
}
exists 查询和 missing 查询
exists 查询和 missing 查询被用于查找那些指定字段中有值 (exists) 或无值 (missing) 的文档。这与SQL中的 IS_NULL (missing) 和 NOT IS_NULL (exists) 在本质上具有共性：
{
"exists": {
"field": "title"
}
}
bool查询
ool 查询来实现你的需求。这种查询将多查询组合在一起，成为用户自己想要的布尔查询。它接收以下参数：
- must 文档 必须 匹配这些条件才能被包含进来。
- must_not 文档 必须不 匹配这些条件才能被包含进来。
- should 如果满足这些语句中的任意语句，将增加 _score ，否则，无任何影响。它们主要用于修正每个文档的相关性得分。
- filter 必须 匹配，但它以不评分、过滤模式来进行。这些语句对评分没有贡献，只是根据过滤标准来排除或包含文档。
下面的查询用于查找 title 字段匹配 how to make millions 并且不被标识为 spam 的文档。那些被标识为 starred 或在2014之后的文档，将比另外那些文档拥有更高的排名。如果 两者 都满足，那么它排名将更高：
{
"bool": {
"must": { "match": { "title": "how to make millions" }},
"must_not": { "match": { "tag": "spam" }},
"should": [
{ "match": { "tag": "starred" }},
{ "range": { "date": { "gte": "2014-01-01" }}}
]
}
}
如果我们不想因为文档的时间而影响得分，可以用 filter 语句来重写前面的例子：
{
"bool": {
"must": { "match": { "title": "how to make millions" }},
"must_not": { "match": { "tag": "spam" }},
"should": [
{ "match": { "tag": "starred" }}
],
"filter": {
"range": { "date": { "gte": "2014-01-01" }}
}
}
}
指定 boost 来控制任何查询语句的相对的权重
boost 的默认值为 1 ，大于 1 会提升一个语句的相对权重。所以下面重写之前的查询：
GET /_search
{
"query": {
"bool": {
"must": {
"match": {
"content": {
"query": "full text search",
"operator": "and"
}
}
},
"should": [
{ "match": {
"content": {
"query": "Elasticsearch",
"boost": 3
}
}},
{ "match": {
"content": {
"query": "Lucene",
"boost": 2
}
}}
]
}
}
}
boost 参数被用来提升一个语句的相对权重（ boost 值大于 1 ）或降低相对权重（ boost 值处于 0 到 1 之间），但是这种提升或降低并不是线性的，换句话说，如果一个 boost 值为 2 ，并不能获得两倍的评分 _score 。
相反，新的评分 _score 会在应用权重提升之后被 归一化 ，每种类型的查询都有自己的归一算法，细节超出了本书的范围，所以不作介绍。简单的说，更高的 boost 值为我们带来更高的评分 _score 。
如果不基于 TF/IDF 要实现自己的评分模型，我们就需要对权重提升的过程能有更多控制，可以使用 function_score 查询操纵一个文档的权重提升方式而跳过归一化这一步骤。
constant_score
尽管没有 bool 查询使用这么频繁，constant_score 查询也是你工具箱里有用的查询工具。它将一个不变的常量评分应用于所有匹配的文档。它被经常用于你只需要执行一个 filter 而没有其它查询
有时候我们根本不关心 TF/IDF ， 只想知道一个词是否在某个字段中出现过。可能搜索一个度假屋并希望它能尽可能有以下设施：
- WiFi
- Garden（花园）
- Pool（游泳池）
这个度假屋的文档如下：
{ “description”: “A delightful four-bedroomed house with … ” }
可以用简单的 match 查询进行匹配：
GET /_search
{
"query": {
"match": {
"description": "wifi garden pool"
}
}
}但这并不是真正的 全文搜索 ，此种情况下，TF/IDF 并无用处。==我们既不关心 wifi 是否为一个普通词，也不关心它在文档中出现是否频繁，关心的只是它是否曾出现过。实际上，我们希望根据房屋不同设施的数量对其排名——==设施越多越好====。 如果设施出现，则记 1 分，不出现记 0 分。
==在 constant_score 查询中，它可以包含查询或过滤，为任意一个匹配的文档指定评分 1 ，忽略 TF/IDF 信息：==
GET /_search
{
"query": {
"bool": {
"should": [
{ "constant_score": {
"query": { "match": { "description": "wifi" }}
}},
{ "constant_score": {
"query": { "match": { "description": "garden" }}
}},
{ "constant_score": {
"query": { "match": { "description": "pool" }}
}}
]
}
}
}或许不是所有的设施都同等重要——对某些用户来说有些设施更有价值。如果最重要的设施是游泳池，那我们可以为更重要的设施增加权重：
GET /_search
{
"query": {
"bool": {
"should": [
{ "constant_score": {
"query": { "match": { "description": "wifi" }}
}},
{ "constant_score": {
"query": { "match": { "description": "garden" }}
}},
{ "constant_score": {
"boost": 2
"query": { "match": { "description": "pool" }}
}}
]
}
}
}最终的评分并不是所有匹配语句的简单求和， 协调因子（coordination factor） 和 查询归一化因子（query normalization factor） 仍然会被考虑在内。
我们可以给 features 字段加上 not_analyzed 类型来提升度假屋文档的匹配能力：
{ “features”: [ “wifi”, “pool”, “garden” ] }
默认情况下，一个 not_analyzed 字段会禁用 字段长度归一值（field-length norms） 的功能， 并将 index_options 设为 docs 选项，禁用 词频 ，但还是存在问题：每个词的 倒排文档频率 仍然会被考虑。
可以采用与之前相同的方法 constant_score 查询来解决这个问题：
GET /_search
{
"query": {
"bool": {
"should": [
{ "constant_score": {
"query": { "match": { "features": "wifi" }}
}},
{ "constant_score": {
"query": { "match": { "features": "garden" }}
}},
{ "constant_score": {
"boost": 2
"query": { "match": { "features": "pool" }}
}}
]
}
}
}实际上，每个设施都应该看成一个过滤器，对于度假屋来说要么具有某个设施要么没有——过滤器因为其性质天然合适。而且，如果使用过滤器，我们还可以利用缓存。
这里的问题是：过滤器无法计算评分。这样就需要寻求一种方式将过滤器和查询间的差异抹平。 function_score 查询不仅正好可以扮演这个角色，而且有更强大的功能。
游标查询 Scroll
scroll 查询 可以用来对 Elasticsearch 有效地执行大批量的文档查询，而又不用付出深度分页那种代价。
游标查询允许我们 先做查询初始化，然后再批量地拉取结果。 这有点儿像传统数据库中的 cursor 。
游标查询会取某个时间点的快照数据。 查询初始化之后索引上的任何变化会被它忽略。 它通过保存旧的数据文件来实现这个特性，结果就像保留初始化时的索引 视图 一样。
深度分页的代价根源是结果集全局排序，如果去掉全局排序的特性的话查询结果的成本就会很低。 游标查询用字段 _doc 来排序。 这个指令让 Elasticsearch 仅仅从还有结果的分片返回下一批结果。
启用游标查询可以通过在查询的时候设置参数 scroll 的值为我们期望的游标查询的过期时间。 游标查询的过期时间会在每次做查询的时候刷新，所以这个时间只需要足够处理当前批的结果就可以了，而不是处理查询结果的所有文档的所需时间。 这个过期时间的参数很重要，因为保持这个游标查询窗口需要消耗资源，所以我们期望如果不再需要维护这种资源就该早点儿释放掉。 设置这个超时能够让 Elasticsearch 在稍后空闲的时候自动释放这部分资源。
GET /old_index/_search?scroll=1m //保持游标查询窗口一分钟。
{
"query": { "match_all": {}},
"sort" : ["_doc"], //关键字 _doc 是最有效的排序顺序。
"size": 1000
}
这个查询的返回结果包括一个字段 _scroll_id， 它是一个base64编码的长字符串 (((“scroll_id”))) 。 现在我们能传递字段 _scroll_id 到 _search/scroll 查询接口获取下一批结果：
多字段映射
为了获取更好的匹配，有时候我们需要对一个字段进行很多种不同的匹配，这样来提高正确率
全文搜索被称作是 召回率（Recall） 与 精确率（Precision） 的战场： 召回率 ——返回结果中的所有文档都是相关的； 精确率 ——返回结果中没有不相关的文档。目的是在结果的第一页中为用户呈现最为相关的文档。
为了提高召回率的效果，我们扩大搜索范围 ——不仅返回与用户搜索词精确匹配的文档，还会返回我们认为与查询相关的所有文档。如果一个用户搜索 “quick brown box” ，一个包含词语 fast foxes 的文档被认为是非常合理的返回结果。
如果包含词语 fast foxes 的文档是能找到的唯一相关文档，那么它会出现在结果列表的最上面，但是，如果有 100 个文档都出现了词语 quick brown fox ，那么这个包含词语 fast foxes 的文档当然会被认为是次相关的，它可能处于返回结果列表更下面的某个地方。当包含了很多潜在匹配之后，我们需要将最匹配的几个置于结果列表的顶部。
提高全文相关性精度的常用方式是为同一文本建立多种方式的索引， 每种方式都提供了一个不同的相关度信号 signal 。主字段会包括最广匹配（broadest-matching）形式的词去尽可能的匹配更多的文档。举个例子，我们可以进行以下操作：
- 使用词干提取来索引 jumps 、 jumping 和 jumped 样的词，将 jump 作为它们的词根形式。这样即使用户搜索 jumped ，也还是能找到包含 jumping 的匹配的文档。
- 将同义词包括其中，如 jump 、 leap 和 hop 。
- 移除变音或口音词：如 ésta 、 está 和 esta 都会以无变音形式 esta 来索引。
尽管如此，如果我们有两个文档，其中一个包含词 jumped ，另一个包含词 jumping ，用户很可能期望前者能排的更高，因为它正好与输入的搜索条件一致。
为了达到目的，我们可以将相同的文本索引到其他字段从而提供更为精确的匹配。一个字段可能是为词干未提取过的版本，另一个字段可能是变音过的原始词，第三个可能使用 shingles 提供 词语相似性 信息。这些其他的字段作为提高每个文档的相关度评分的信号 signals ，能匹配字段的越多越好。
一个文档如果与广度匹配的主字段相匹配，那么它会出现在结果列表中。如果文档同时又与 signal 信号字段匹配，那么它会获得额外加分，系统会提升它在结果列表中的位置。
我们会在本书稍后对同义词、词相似性、部分匹配以及其他潜在的信号进行讨论，但这里只使用词干已提取（stemmed）和未提取（unstemmed）的字段作为简单例子来说明这种技术。
首先要做的事情就是对我们的字段索引两次： 一次使用词干模式以及一次非词干模式。为了做到这点，采用 multifields 来实现，已经在 multifields 有所介绍：
PUT /my_index
{
"settings": { "number_of_shards": 1 },
"mappings": {
"my_type": {
"properties": {
"title": {
"type": "string",
"analyzer": "english",//title字段使用 english 英语分析器来提取词干。
"fields": {
"std": { //title.std 字段使用 standard 标准分析器，所以没有词干提取。
"type": "string",
"analyzer": "standard"
}
}
}
}
}
}
}
sort排序
为了按照相关性来排序，需要将相关性表示为一个数值。在 Elasticsearch 中， 相关性得分 由一个浮点数进行表示，并在搜索结果中通过 _score 参数返回， 默认排序是 _score 降序。
有时，相关性评分对你来说并没有意义。这就需要我们按照自己的方式排序
按字段的值排序
GET /_search
{
"query" : {
"bool" : {
"filter" : { "term" : { "user_id" : 1 }}
}
},
"sort": { "date": { "order": "desc" }}
}
多级排序
GET /_search
{
"query" : {
"bool" : {
"must": { "match": { "tweet": "manage text search" }},
"filter" : { "term" : { "user_id" : 2 }}
}
},
"sort": [
{ "date": { "order": "desc" }},
{ "_score": { "order": "desc" }}
]
}
扫一扫
628
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
