Elasticsearch7.x——Search API详解

傷城~ 2024-02-21 09:07 65阅读 0赞

#### 目录 ####

*  Search API
 *   *  1、URI模式
     *  2、Body模式
     *   *  2.1、Explain参数
         *  2.2、折叠结果（collapse）
         *   *  2.2.1、展开折叠结果
             *  2.2.2、二级折叠
         *  2.3、对结果分页
         *  2.4、高亮结果
         *   *  2.4.1、unified高亮器
             *  2.4.2、plain高亮器
             *  2.4.3、fvh高亮器
             *  2.4.4、为字段设置高亮器
             *  2.4.5、highlight\_query查询
             *  2.4.6、高亮器类型选择
             *  2.4.7、配置高亮器标签
             *  2.4.8、\_source字段高亮显示
             *  2.4.9、高亮显示所有字段
             *  2.4.10、组合字段高亮显示
             *  2.4.11、高亮字段排序
             *  2.4.12、高亮片段控制
             *  2.4.13、Posting List的应用
             *  2.4.14、为Plain高亮器指定片段
         *  2.5、索引加权
         *  2.6、命中文档嵌套
         *   *  2.6.1、嵌套的inner\_hits
             *  2.6.2、嵌套内部名字和\_source
             *  2.6.3、嵌套对象字段和内部命中的层次级别
             *  2.6.4、父子嵌套
         *  2.7、分数值过滤
         *  2.8、查询命名
         *  2.9、post\_filter过滤
         *  2.10、分片选择（preference）
         *  2.11、重排序
         *  2.12、脚本字段
         *  2.13、滚动查询
         *   *  2.13.1、保持搜索上下文处于活跃状态
             *  2.13.2、清理搜索上下文
             *  2.13.3、切片
         *  2.14、search\_after参数
         *  2.15、搜索类型
         *  2.16、排序
         *   *  2.16.1、排序方式
             *  2.16.2、多值字段排序模式
             *  2.16.3、嵌套对象的排序
             *  2.16.4、缺失值的处理
             *  2.16.5、地理距离排序
             *   *  2.16.5.1、JSON经纬度格式
                 *  2.16.5.2、逗号分隔格式
                 *  2.16.5.3、pin码格式
                 *  2.16.5.4、数组格式
                 *  2.16.5.5、两点距离格式
             *  2.16.6、自定义脚本排序
         *  2.17、\_source字段过滤
         *  2.18、存储字段
         *  2.19、total返回值详解（track\_total\_hits）
         *  2.20、版本控制（\_version）
     *  3、返回索引分片信息（\_search\_shards）
     *  4、Count API
     *  5、Validate API
     *  6、调试（\_explain）

## Search API ##

搜索API(\_search)允许用来执行搜索查询并返回匹配的结果。 可以使用简单查询字符串作为参数提供查询(URI形式)，也可以使 用请求正文(body形式)。大多数搜索API都是支持多索引的， Explain API除外(用于调试性能)。

//语法
 GET /<index>/_search
 GET /_search
 POST /<index>/_search
 POST /_search

所有搜索API都支持跨索引机制，并支持多索引语法。例如，搜 索twitter索引中的所有文档:

GET /twitter/_search?q=user:kimchy

还可以在多个索引中搜索具有特定标记的所有文档，例如当每个 用户有一个索引时:

GET /kimchy,Elasticsearch/_search?q=tag:now

或者使用\_all搜索所有可用索引:

GET /_all/_search?q=tag:now

为了确保快速响应，如果一个或多个分片失败，搜索API将以部 分结果响应。

### 1、URI模式 ###

通过提供请求参数，可以纯粹使用URI执行搜索请求。在使用此 模式执行搜索时，并非所有搜索选项都可用，但对于快速的“测试” 来说，它非常方便。

GET twitter/_search?1=user:kimchy

URI搜索模式支持的参数如下表：  
![在这里插入图片描述][00371f4606c9467eb37addd85beda29b.png]

### 2、Body模式 ###

搜索请求可以在请求正文中使用Query DSL:

GET /twitter/_search
    {
        
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

Body搜索模式支持的参数如下表：  
![在这里插入图片描述][68bee673ad314849b7fe6ea92f460e6f.png]

> 注 意 : search\_type 、 request\_cache 和 allow\_partial\_search\_results必须作为查询字符串参数传递(不能放在body里面，要放在URL里面)。搜索请求的其余部分应该在主体内 部传递。正文内容也可以作为名为source的REST参数传递。HTTP GET 和HTTP POST都可以用于执行带Body的搜索。

terminate\_after始终在post\_filter之后应用，并在分片上收集到 足够的命中结果后停止查询和聚合。聚合上的文档计数可能不会反映 响应中的hits.total，因为聚合是在post\_filter之前应用的。

如果只需要知道是否有任何文档匹配特定的查询，可以将size设 置为0，以表示对搜索结果不感兴趣。此外，还可以将 terminate\_after设置为1，以指示只要找到第一个匹配的文档(每个 分片)，就可以终止查询执行。示例如下:

GET /_search?q=message:number&size=0&terminate_after=1

{
        
      "took": 3,
      "timed_out": false,
      "terminated_early": true,
      "_shards": {
        
        "total": 1,
        "successful": 1,
        "skipped" : 0,
        "failed": 0
      },
      "hits": {
        
        "total" : {
        
            "value": 1,
            "relation": "eq"
        },
        "max_score": null,
        "hits": []
      }
    }

可以看到，响应结果中不包含任何文档，因为size设置为0。 hits.total将等于0，表示没有匹配的文档，或者大于0，表示在提前 终止查询时，至少有多个文档匹配此查询。此外，如果查询提前终 止，则在响应中将terminated\_early标志设置为true。

响应中所用的时间took是处理此请求所用的毫秒数，从节点收到 查询后快速开始，直到完成所有与搜索相关的工作，然后再将上述 JSON返回到客户机。这意味着它包括在线程池中等待、在整个集群 中执行分布式搜索以及收集所有结果所花费的时间。

#### 2.1、Explain参数 ####

Explain参数是Elasticsearch提供的辅助API，经常不为人所知 和所用。Explain参数用来帮助分析文档的相关性分数是如何计算出 来的。

GET /test/_search
    {
        
      "explain": true,
      "query": {
        
        "match": {
        
          "text": "hello"
        }
      }
    }

{
        
      "took" : 0,
      "timed_out" : false,
      "_shards" : {
        
        "total" : 1,
        "successful" : 1,
        "skipped" : 0,
        "failed" : 0
      },
      "hits" : {
        
        "total" : {
        
          "value" : 1,
          "relation" : "eq"
        },
        "max_score" : 0.2876821,
        "hits" : [
          {
        
            "_shard" : "[test][0]",
            "_node" : "Cc6ARDA6TY-poOdtxvsA6g",
            "_index" : "test",
            "_type" : "_doc",
            "_id" : "1",
            "_score" : 0.2876821,
            "_source" : {
        
              "text" : "hello world",
              "flag" : "foo"
            },
            "_explanation" : {
        
              "value" : 0.2876821,
              "description" : "weight(text:hello in 0) [PerFieldSimilarity], result of:",
              "details" : [
                {
        
                  "value" : 0.2876821,
                  "description" : "score(freq=1.0), computed as boost * idf * tf from:",
                  "details" : [
                    {
        
                      "value" : 2.2,
                      "description" : "boost",
                      "details" : [ ]
                    },
                    {
        
                      "value" : 0.2876821,
                      "description" : "idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:",
                      "details" : [
                        {
        
                          "value" : 1,
                          "description" : "n, number of documents containing term",
                          "details" : [ ]
                        },
                        {
        
                          "value" : 1,
                          "description" : "N, total number of documents with field",
                          "details" : [ ]
                        }
                      ]
                    },
                    {
        
                      "value" : 0.45454544,
                      "description" : "tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:",
                      "details" : [
                        {
        
                          "value" : 1.0,
                          "description" : "freq, occurrences of term within document",
                          "details" : [ ]
                        },
                        {
        
                          "value" : 1.2,
                          "description" : "k1, term saturation parameter",
                          "details" : [ ]
                        },
                        {
        
                          "value" : 0.75,
                          "description" : "b, length normalization parameter",
                          "details" : [ ]
                        },
                        {
        
                          "value" : 2.0,
                          "description" : "dl, length of field",
                          "details" : [ ]
                        },
                        {
        
                          "value" : 2.0,
                          "description" : "avgdl, average length of field",
                          "details" : [ ]
                        }
                      ]
                    }
                  ]
                }
              ]
            }
          }
        ]
      }
    }

结果形式上比较复杂，里面最重要的内容就是对文档计算得到的 总分以及总分的计算过程。如果总分等于0，则该文档将不能匹配给 定的查询。另一个重要内容是关于不同打分项的描述信息，根据查询 类型的不同，打分项会以不同方式对最后得分产生影响。

#### 2.2、折叠结果（collapse） ####

允许基于字段值折叠(collapse)搜索结果。折叠是通过每个折 叠键仅选择顶部排序的文档来完成的。其实就是按照某个字段分组， 每个分组只取一条结果。例如，下面的查询示例为每个用户检索最好 的tweet，并按喜欢的次数(likes字段)对其进行排序。

GET /twitter/_search
    {
        
        "query": {
        
            "match": {
        
                "message": "elasticsearch"
            }
        },
        "collapse" : {
        
            "field" : "user" 
        },
        "sort": ["likes"], 
        "from": 10 
    }

> 注意:响应中的命中total指示匹配文档的数量，是非折叠的结 果。非重复组(折叠后的数量)的总数是未知的。

> 用于折叠的字段必须是单值keyword或数字numeric字段，而且 doc\_values属性开启。

示例：根据age字段折叠结果集，按balance倒序排序

GET /bank/_search
    {
        
      "query": {
        
        "match": {
        
          "address": "street"
        }
      },
      "collapse": {
        
        "field": "age"
      },
      "sort": [
        {
        
          "balance": {
        
            "order": "desc"
          }
        }
      ],
      "from": 0,
      "size": 2
    }

{
        
      "took" : 0,
      "timed_out" : false,
      "_shards" : {
        
        "total" : 1,
        "successful" : 1,
        "skipped" : 0,
        "failed" : 0
      },
      "hits" : {
        
        "total" : {
        
          "value" : 385,
          "relation" : "eq"
        },
        "max_score" : null,
        "hits" : [
          {
        
            "_index" : "bank",
            "_type" : "_doc",
            "_id" : "854",
            "_score" : null,
            "_source" : {
        
              "account_number" : 854,
              "balance" : 49795,
              "firstname" : "Jimenez",
              "lastname" : "Barry",
              "age" : 25,
              "gender" : "F",
              "address" : "603 Cooper Street",
              "employer" : "Verton",
              "email" : "jimenezbarry@verton.com",
              "city" : "Moscow",
              "state" : "AL"
            },
            "fields" : {
        
              "age" : [
                25
              ]
            },
            "sort" : [
              49795
            ]
          },
          {
        
            "_index" : "bank",
            "_type" : "_doc",
            "_id" : "926",
            "_score" : null,
            "_source" : {
        
              "account_number" : 926,
              "balance" : 49433,
              "firstname" : "Welch",
              "lastname" : "Mcgowan",
              "age" : 21,
              "gender" : "M",
              "address" : "833 Quincy Street",
              "employer" : "Atomica",
              "email" : "welchmcgowan@atomica.com",
              "city" : "Hampstead",
              "state" : "VT"
            },
            "fields" : {
        
              "age" : [
                21
              ]
            },
            "sort" : [
              49433
            ]
          }
        ]
      }
    }

##### 2.2.1、展开折叠结果 #####

可以使用inner\_hits选项展开每个折叠的顶部结果：

GET /bank/_search
    {
        
      "query": {
        
        "match": {
        
          "address": "street"
        }
      },
      "collapse": {
        
        "field": "age",
        "inner_hits": {
        
          "name":"inner_list",
          "size":2,
          "sort":[{
        "balance":{
        "order":"desc"}}]
        },
        "max_concurrent_group_searches": 4
      },
      "sort": [
        {
        
          "balance": {
        
            "order": "desc"
          }
        }
      ],
      "from": 0,
      "size": 1
    }

*  name：响应中每个组内部展开结果使用的名称
 *  size：每个折叠键要检索的结果数，也就是每组返回多少个结 果。
 *  sort：如何对每组中的文档进行排序。
 *  max\_concurrent\_group\_searches：允许每个组检索内部结果的并发请求数。

{
        
      "took" : 1,
      "timed_out" : false,
      "_shards" : {
        
        "total" : 1,
        "successful" : 1,
        "skipped" : 0,
        "failed" : 0
      },
      "hits" : {
        
        "total" : {
        
          "value" : 385,
          "relation" : "eq"
        },
        "max_score" : null,
        "hits" : [
          {
        
            "_index" : "bank",
            "_type" : "_doc",
            "_id" : "854",
            "_score" : null,
            "_source" : {
        
              "account_number" : 854,
              "balance" : 49795,
              "firstname" : "Jimenez",
              "lastname" : "Barry",
              "age" : 25,
              "gender" : "F",
              "address" : "603 Cooper Street",
              "employer" : "Verton",
              "email" : "jimenezbarry@verton.com",
              "city" : "Moscow",
              "state" : "AL"
            },
            "fields" : {
        
              "age" : [
                25
              ]
            },
            "sort" : [
              49795
            ],
            "inner_hits" : {
        
              "inner_list" : {
        
                "hits" : {
        
                  "total" : {
        
                    "value" : 16,
                    "relation" : "eq"
                  },
                  "max_score" : null,
                  "hits" : [
                    {
        
                      "_index" : "bank",
                      "_type" : "_doc",
                      "_id" : "854",
                      "_score" : null,
                      "_source" : {
        
                        "account_number" : 854,
                        "balance" : 49795,
                        "firstname" : "Jimenez",
                        "lastname" : "Barry",
                        "age" : 25,
                        "gender" : "F",
                        "address" : "603 Cooper Street",
                        "employer" : "Verton",
                        "email" : "jimenezbarry@verton.com",
                        "city" : "Moscow",
                        "state" : "AL"
                      },
                      "sort" : [
                        49795
                      ]
                    },
                    {
        
                      "_index" : "bank",
                      "_type" : "_doc",
                      "_id" : "835",
                      "_score" : null,
                      "_source" : {
        
                        "account_number" : 835,
                        "balance" : 46558,
                        "firstname" : "Glover",
                        "lastname" : "Rutledge",
                        "age" : 25,
                        "gender" : "F",
                        "address" : "641 Royce Street",
                        "employer" : "Ginkogene",
                        "email" : "gloverrutledge@ginkogene.com",
                        "city" : "Dixonville",
                        "state" : "VA"
                      },
                      "sort" : [
                        46558
                      ]
                    }
                  ]
                }
              }
            }
          }
        ]
      }
    }

还可以为每个折叠组定义不同的展开请求参数。当希望获得折叠 的多个表示形式时，这很有用。示例如下:

GET /twitter/_search
    {
        
        "query": {
        
            "match": {
        
                "message": "elasticsearch"
            }
        },
        "collapse" : {
        
            "field" : "user", 
            "inner_hits": [
                {
        
                    "name": "most_liked",  
                    "size": 3,
                    "sort": ["likes"]
                },
                {
        
                    "name": "most_recent", 
                    "size": 3,
                    "sort": [{
         "date": "asc" }]
                }
            ]
        },
        "sort": ["likes"]
    }

##### 2.2.2、二级折叠 #####

二级折叠也是支持的，并可应用于inner\_hits。例如，下面的请 求为每个国家(country字段)查找得分最高的tweet，在每个国家内 为每个用户查找得分最高的tweet。

GET /twitter/_search
    {
        
        "query": {
        
            "match": {
        
                "message": "elasticsearch"
            }
        },
        "collapse" : {
        
            "field" : "country",
            "inner_hits" : {
        
                "name": "by_location",
                "collapse" : {
        "field" : "user"},
                "size": 3
            }
        }
    }

{
        
        ...
        "hits": [
            {
        
                "_index": "twitter",
                "_type": "_doc",
                "_id": "9",
                "_score": ...,
                "_source": {
        ...},
                "fields": {
        "country": ["UK"]},
                "inner_hits":{
        
                    "by_location": {
        
                        "hits": {
        
                           ...,
                           "hits": [
                              {
        
                                ...
                                "fields": {
        "user" : ["user124"]}
                              },
                              {
        
                                ...
                                "fields": {
        "user" : ["user589"]}
                              },
                              {
        
                                ...
                                 "fields": {
        "user" : ["user001"]}
                              }
                           ]
                        }
                     }
                }
            },
            {
        
                "_index": "twitter",
                "_type": "_doc",
                "_id": "1",
                "_score": ..,
                "_source": {
        ...},
                "fields": {
        "country": ["Canada"]},
                "inner_hits":{
        
                    "by_location": {
        
                        "hits": {
        
                           ...,
                           "hits": [
                              {
        
                                ...
                                "fields": {
        "user" : ["user444"]}
                              },
                              {
        
                                ...
                                "fields": {
        "user" : ["user1111"]}
                              },
                              {
        
                                ...
                                 "fields": {
        "user" : ["user999"]}
                              }
                           ]
                        }
                     }
                }
    
            },
            ....
        ]
    }

> 第二级折叠不允许再展开。

#### 2.3、对结果分页 ####

可以使用from和size参数对结果进行分页。from参数定义要获取 的第一个结果的偏移量，size参数表示要返回的最大结果的数量。

尽管可以将from和size设置为请求参数，但它们也可以在body中 设置。from默认值为0，size默认值为10，示例如下。

GET /_search
    {
        
    	"from":0,
    	"size":10,
    	"query": {
        
    		"term":{
        "user":"kimchy"}
    	}
    }

> 注意:from+size不能超过index.max\_result\_window参数设置的 值，后者的默认值为10000。增大此参数，会导致系统开销线性增大。

#### 2.4、高亮结果 ####

高亮器(Highlighter)用来标识出搜索结果中的一个或多个字段 中需要突出显示的代码段，以便向用户显示查询匹配的位置。

当请求中包括高亮的参数设置时，响应结果包含每个搜索命中的 高亮元素，其中包括突出显示的字段和突出显示的片段。

高亮器在提取要突出显示的项时不反映查询的布尔逻辑。因此， 对于某些复杂的布尔查询(例如嵌套布尔查询、 minimum\_should\_match等)，可能会突出显示与查询匹配不对应 的部分文档。

高亮需要字段有实际内容(索引时将store设置为true)。如果未 存储字段(映射未将store设置为true)，则加载实际的\_source，并 从\_source提取相关字段。

例如，使用默认高亮器对每条搜索结果中的content字段突出显 示，请在请求正文中包含一个highlight对象，该对象指定content字 段:

GET /bank/_search
    {
        
      "query": {
        
        "match": {
        
          "firstname": "Jimenez"
        }
      },
      "highlight": {
        
        "fields": {
        
          "firstname": {
        }
        }
      }
    }

{
 
 "took" : 46,
 "timed_out" : false,
 "_shards" : {
 
 "total" : 1,
 "successful" : 1,
 "skipped" : 0,
 "failed" : 0
 },
 "hits" : {
 
 "total" : {
 
 "value" : 1,
 "relation" : "eq"
 },
 "max_score" : 6.5052857,
 "hits" : [
 {
 
 "_index" : "bank",
 "_type" : "_doc",
 "_id" : "854",
 "_score" : 6.5052857,
 "_source" : {
 
 "account_number" : 854,
 "balance" : 49795,
 "firstname" : "Jimenez",
 "lastname" : "Barry",
 "age" : 25,
 "gender" : "F",
 "address" : "603 Cooper Street",
 "employer" : "Verton",
 "email" : "jimenezbarry@verton.com",
 "city" : "Moscow",
 "state" : "AL"
 },
 "highlight" : {
 
 "firstname" : [
 "Jimenez"
 ]
 }
 }
 ]
 }
 }

Elasticsearch支持三种高亮器:unified(基于BM25算法的高 亮器)、plain(Lucene标准高亮器)和fvh(快速矢量高亮器)。实 际应用中，可以为每个字段指定不同的高亮。

##### 2.4.1、unified高亮器 #####

unified高亮器使用的是Lucene Unified Highlighter。这个高亮 器将文本分成句子，并使用BM25算法对单个句子进行评分，就如同 它们是语料库中的文档。这是默认的高亮器。

##### 2.4.2、plain高亮器 #####

plain高亮器使用标准Lucene高亮器。它试图从词的重要性和短 语查询中的任何词定位条件来反映查询匹配逻辑。

plain高亮器最适合在单个字段中突出显示简单查询匹配项。为了 准确反映查询逻辑，它会创建一个很小的内存中的索引，并通过 Lucene的查询执行计划器重新运行原始查询条件，以访问当前文档的 低级匹配信息。对于需要突出显示的每个字段和每个文档，重复此操 作。如果想突出显示许多文档中的许多字段，进行较为复杂的查询， 作者建议在postings或term\_vector字段上使用unified高亮器。

##### 2.4.3、fvh高亮器 #####

fvh高亮器使用Lucene快速矢量高亮器。此高亮器可用于在映射 中将term\_vector设置为`with_positions_offsets`的字段。此高亮器特 点如下:

*  可以通过boundary\_scanner参数进行自定义设置。
 *  需要设置term\_vector为with\_positions\_offsets，以增加索 引的大小。
 *  可以将多个字段中的匹配项组合为一个结果。
 *  可以为不同位置的匹配分配不同的权重，将短语匹配排序在 Term匹配前面，主要应用于boost查询(对某个字段加 权)。

##### 2.4.4、为字段设置高亮器 #####

如下示例中，对每个字段进行单独设置，覆盖全局高亮设置。

GET /_search
 {
 
 "query" : {
 
 "match": {
 "user": "kimchy" }
 },
 "highlight" : {
 
 "number_of_fragments" : 3,
 "fragment_size" : 150,
 "fields" : {
 
 "body" : {
 "pre_tags" : [""], "post_tags" : [""] },
 "blog.title" : {
 "number_of_fragments" : 0 },
 "blog.author" : {
 "number_of_fragments" : 0 },
 "blog.comment" : {
 "number_of_fragments" : 5, "order" : "score" }
 }
 }
 }

##### 2.4.5、highlight\_query查询 #####

可以指定highlight\_query查询(重评分查询)，以便在突出显 示时考虑其他信息。例如，下面的查询同时包含搜索查询和重新评分查询，如果用了highlight\_query查询，突出显示将只考虑搜索查 询。

GET /_search
    {
        
        "query" : {
        
            "match": {
        
                "comment": {
        
                    "query": "foo bar"
                }
            }
        },
        "rescore": {
        
            "window_size": 50,
            "query": {
        
                "rescore_query" : {
        
                    "match_phrase": {
        
                        "comment": {
        
                            "query": "foo bar",
                            "slop": 1
                        }
                    }
                },
                "rescore_query_weight" : 10
            }
        },
        "_source": false,
        "highlight" : {
        
            "order" : "score",
            "fields" : {
        
                "comment" : {
        
                    "fragment_size" : 150,
                    "number_of_fragments" : 3,
                    "highlight_query": {
        
                        "bool": {
        
                            "must": {
        
                                "match": {
        
                                    "comment": {
        
                                        "query": "foo bar"
                                    }
                                }
                            },
                            "should": {
        
                                "match_phrase": {
        
                                    "comment": {
        
                                        "query": "foo bar",
                                        "slop": 1,
                                        "boost": 10.0
                                    }
                                }
                            },
                            "minimum_should_match": 0
                        }
                    }
                }
            }
        }
    }

##### 2.4.6、高亮器类型选择 #####

类型字段type允许强制使用特定的高亮器类型。允许值为 unified、plain和fvh。以下是强制使用plain高亮器的示例:

GET /_search
    {
        
        "query" : {
        
            "match": {
         "user": "kimchy" }
        },
        "highlight" : {
        
            "fields" : {
        
                "comment" : {
        "type" : "plain"}
            }
        }
    }

##### 2.4.7、配置高亮器标签 #####

默认情况下，高亮显示的文本包裹在``和``中。这可以 通过设置pre\_tags标记和post\_tags标记来控制，例如:

GET /_search
 {
 
 "query" : {
 
 "match": {
 "user": "kimchy" }
 },
 "highlight" : {
 
 "pre_tags" : ["<tag1>"],
 "post_tags" : ["</tag1>"],
 "fields" : {
 
 "body" : {
 }
 }
 }
 }

当使用快速矢量高亮器时，可以指定其他标签，并按重要性进行 排序，示例如下。

GET /_search
 {
 
 "query" : {
 
 "match": {
 "user": "kimchy" }
 },
 "highlight" : {
 
 "pre_tags" : ["<tag1>", "<tag2>"],
 "post_tags" : ["</tag1>", "</tag2>"],
 "fields" : {
 
 "body" : {
 }
 }
 }
 }

还可以使用内置样式的styled模式:

GET /_search
    {
        
        "query" : {
        
            "match": {
         "user": "kimchy" }
        },
        "highlight" : {
        
            "tags_schema" : "styled",
            "fields" : {
        
                "comment" : {
        }
            }
        }
    }

##### 2.4.8、\_source字段高亮显示 #####

可以强制高亮显示\_source中的字段，即使字段是单独存储的， 示例如下:

GET /_search
    {
        
        "query" : {
        
            "match": {
         "user": "kimchy" }
        },
        "highlight" : {
        
            "fields" : {
        
                "comment" : {
        "force_source" : true}
            }
        }
    }

##### 2.4.9、高亮显示所有字段 #####

默认情况下，只高亮显示包含查询匹配的字段。设置 require\_field\_match为false可以高亮显示所有字段，示例如下。

GET /_search
 {
 
 "query" : {
 
 "match": {
 "user": "kimchy" }
 },
 "highlight" : {
 
 "require_field_match": false,
 "fields": {
 
 "body" : {
 "pre_tags" : [""], "post_tags" : [""] }
 }
 }
 }

##### 2.4.10、组合字段高亮显示 #####

只有fvh高亮器支持这个特性。快速矢量高亮器可以把多个字段的 匹配结果组合成单个字段来高亮显示。对于以不同方式分析同一字符 串的多字段来说，这是最直观的。所有匹配的matched\_fields字段都 必须将term\_vector设置为with\_positions\_offsets，但只有匹配项组 合到的字段才会被加载，因此最好将该字段的store属性设置为 true(加速查询，无须加载\_source)。

在 下 面 的 示 例 中 ， comment 由 英 语 分 析 器 分 析 ， comment.plain由标准分析器分析。

GET /_search
    {
        
        "query": {
        
            "query_string": {
        
                "query": "comment.plain:running scissors",
                "fields": ["comment"]
            }
        },
        "highlight": {
        
            "order": "score",
            "fields": {
        
                "comment": {
        
                    "matched_fields": ["comment", "comment.plain"],
                    "type" : "fvh"
                }
            }
        }
    }

以上两种匹配查询既会匹配run with scissors，又会匹配 running with scissors。但只会高亮running和scissors，而不会高 亮run。如果这两个短语都出现在一个大文档中，那么running with scissors对应的文档将排在run with scissors对应的文档上方，因为 该片段中有更多的匹配项。用running scissors查询时，默认是OR 的关系，所以只要文档中出现其一就会匹配到，但只会高亮查询词 run和scissors，排序是同时命中两个词的文档会排在只命中一个词 的前面。示例如下。

GET /_search
    {
        
        "query": {
        
            "query_string": {
        
                "query": "running scissors",
                "fields": ["comment", "comment.plain^10"]
            }
        },
        "highlight": {
        
            "order": "score",
            "fields": {
        
                "comment": {
        
                    "matched_fields": ["comment", "comment.plain"],
                    "type" : "fvh"
                }
            }
        }
    }

上面高亮显示了run以及running和scissors，但仍然将 running with scissors匹配的文档排序在run with scissors匹配文 档的前面，因为plain匹配(running)被加权了。

##### 2.4.11、高亮字段排序 #####

Elasticsearch按发送顺序显示高亮字段，但根据JSON规范，对 象是无序的。如果需要明确高亮字的显示顺序，请将高亮字段fields 指定为数组，用法如下。

GET /_search
    {
        
        "highlight": {
        
            "fields": [
                {
         "title": {
        } },
                {
         "text": {
        } }
            ]
        }
    }

##### 2.4.12、高亮片段控制 #####

高亮的每个字段可以控制高亮显示片段的大小(以字符为单位， 默认值为100)，以及要返回的最大片段数(默认值为5)，示例如 下。

GET /_search
    {
        
        "query" : {
        
            "match": {
         "user": "kimchy" }
        },
        "highlight" : {
        
            "fields" : {
        
                "comment" : {
        "fragment_size" : 150, "number_of_fragments" : 3}
            }
        }
    }

除此之外，还可以指定高亮显示的片段按分数排序:

GET /_search
    {
        
        "query" : {
        
            "match": {
         "user": "kimchy" }
        },
        "highlight" : {
        
            "order" : "score",
            "fields" : {
        
                "comment" : {
        "fragment_size" : 150, "number_of_fragments" : 3}
            }
        }
    }

如果number\_of\_fragments值设置为0，则不会生成片段，而是 高亮返回字段的全部内容。如果需要高亮显示短文本(如文档标题或 地址)，但不需要片段，操作非常方便。注意，在这种情况下 fragment\_size被忽略。示例如下。

GET /_search
    {
        
        "query" : {
        
            "match": {
         "user": "kimchy" }
        },
        "highlight" : {
        
            "fields" : {
        
                "body" : {
        },
                "blog.title" : {
        "number_of_fragments" : 0}
            }
        }
    }

使用fvh时，可以使用fragment\_offset参数控制要从中开始高亮 显示的边距。如果没有匹配的片段要高亮显示，则默认情况下不返回 任何内容。相反，可以通过将no\_match\_size(默认值为0)设置为 要返回的文本的长度，从字段开头返回一段文本。实际长度可能比指 定的短或长，因为它试图在单词边界上中断(不会把一个词截断)。

GET /_search
    {
        
        "query" : {
        
            "match": {
         "user": "kimchy" }
        },
        "highlight" : {
        
            "fields" : {
        
                "comment" : {
        
                    "fragment_size" : 150,
                    "number_of_fragments" : 3,
                    "no_match_size": 150
                }
            }
        }
    }

##### 2.4.13、Posting List的应用 #####

Posting List就是一个整型数组，存储了所有符合某个Term的文 档ID。

以下示例在索引映射中设置comment字段以允许使用Posting List高亮显示结果。

PUT /example
    {
        
      "mappings": {
        
        "properties": {
        
          "comment" : {
        
            "type": "text",
            "index_options" : "offsets"
          }
        }
      }
    }

下面是设置comment字段以允许使用term\_vectors向量(这将 导致索引更大)的示例:

PUT /example
    {
        
      "mappings": {
        
        "properties": {
        
          "comment" : {
        
            "type": "text",
            "term_vector" : "with_positions_offsets"
          }
        }
      }
    }

##### 2.4.14、为Plain高亮器指定片段 #####

使用Plain高亮器时，可以在simple片段和span片段之间进行选 择:

GET twitter/_search
    {
        
        "query" : {
        
            "match_phrase": {
         "message": "number 1" }
        },
        "highlight" : {
        
            "fields" : {
        
                "message" : {
        
                    "type": "plain",
                    "fragment_size" : 15,
                    "number_of_fragments" : 3,
                    "fragmenter": "simple"
                }
            }
        }
    }

#### 2.5、索引加权 ####

在搜索多个索引时，可以为每个索引配置不同的权重。当来自一 个索引的命中文档比来自另一个索引的更重要时，这非常方便。

GET /_search
    {
        
        "indices_boost" : {
        
            "index1" : 1.4,
            "index2" : 1.3
        }
    }

这在使用别名或通配符表达式时很重要。如果找到多个匹配项， 将使用第一个匹配项。例如，如果一个索引同时包含在alias1和 index\*中，则将应用1.4的boost值。

GET /_search
    {
        
        "indices_boost" : [
            {
         "alias1" : 1.4 },
            {
         "index*" : 1.3 }
        ]
    }

#### 2.6、命中文档嵌套 ####

父联接(parent-join)和嵌套(nested)功能允许返回在不同 范围内具有匹配项的文档。在父/子案例中，父文档基于子文档中的匹配项返回，或者子文档基于父文档中的匹配项返回。在嵌套的情况 下，基于嵌套内部对象中的匹配项返回文档。

在这两种情况下，导致返回文档的不同范围中的实际匹配都是隐 藏的。在许多情况下，了解哪些内部嵌套对象(对于嵌套对象)或子 /父文档(对于父/子文档)导致返回某些信息是非常必要的。此功 能在搜索响应中返回每次搜索命中的其他嵌套命中，这些嵌套命中导 致搜索命中在不同范围内匹配。

使用方法是通过在nested、has\_child或has\_parent查询和筛选 上定义内部定义inner\_hits。结构如下:

"<query>" : {
 
 "inner_hits" : {
 
 <inner_hits_options>
 }
 }

如果在查询上定义了inner\_hits，那么每个搜索命中都将包含一 个具有以下结构的inner\_hits JSON对象:

"hits": [
 {
 
 "_index": ...,
 "_type": ...,
 "_id": ...,
 "inner_hits": {
 
 "<inner_hits_name>": {
 
 "hits": {
 
 "total": ...,
 "hits": [
 {
 
 "_type": ...,
 "_id": ...,
 ...
 },
 ...
 ]
 }
 }
 },
 ...
 },
 ...
 ]

##### 2.6.1、嵌套的inner\_hits #####

嵌套的inner\_hits可用于将嵌套的内部对象包含为搜索命中的内 部命中。示例如下:

PUT test
    {
        
      "mappings": {
        
        "properties": {
        
          "comments": {
        
            "type": "nested"
          }
        }
      }
    }
    
    PUT test/_doc/1?refresh
    {
        
      "title": "Test title",
      "comments": [
        {
        
          "author": "kimchy",
          "number": 1
        },
        {
        
          "author": "nik9000",
          "number": 2
        }
      ]
    }
    
    POST test/_search
    {
        
      "query": {
        
        "nested": {
        
          "path": "comments",
          "query": {
        
            "match": {
        "comments.number" : 2}
          },
          "inner_hits": {
        } 
        }
      }
    }

{
        
      "took" : 9,
      "timed_out" : false,
      "_shards" : {
        
        "total" : 1,
        "successful" : 1,
        "skipped" : 0,
        "failed" : 0
      },
      "hits" : {
        
        "total" : {
        
          "value" : 1,
          "relation" : "eq"
        },
        "max_score" : 1.0,
        "hits" : [
          {
        
            "_index" : "test",
            "_type" : "_doc",
            "_id" : "1",
            "_score" : 1.0,
            "_source" : {
        
              "title" : "Test title",
              "comments" : [
                {
        
                  "author" : "kimchy",
                  "number" : 1
                },
                {
        
                  "author" : "nik9000",
                  "number" : 2
                }
              ]
            },
            "inner_hits" : {
        
              "comments" : {
        
                "hits" : {
        
                  "total" : {
        
                    "value" : 1,
                    "relation" : "eq"
                  },
                  "max_score" : 1.0,
                  "hits" : [
                    {
        
                      "_index" : "test",
                      "_type" : "_doc",
                      "_id" : "1",
                      "_nested" : {
        
                        "field" : "comments",
                        "offset" : 1
                      },
                      "_score" : 1.0,
                      "_source" : {
        
                        "number" : 2,
                        "author" : "nik9000"
                      }
                    }
                  ]
                }
              }
            }
          }
        ]
      }
    }

在上面的例子中，嵌套元数据\_nested是至关重要的，因为它定 义了这个内部命中来自哪个内部嵌套对象。Field定义嵌套命中来自的 对象数组字段，以及相对于其在\_source中位置的偏移量offset。由于 排序和评分，inner\_hits中命中对象的实际位置通常与定义嵌套内部 对象的位置不同。

默认情况下，也会为inner\_hits中的命中对象返回\_source，但 这可以更改。通过\_source过滤功能可以返回部分字段。如果在嵌套 级别上定义了存储字段，也可以通过fields功能返回这些字段。

一个重要的默认行为是，在返回结果中，inner\_hits元素中的 hits元素的\_source字段只包含定义为\_nested类型的字段。因此在上 面的示例中，每次嵌套命中只返回注释部分，而不是包含注释的顶级 文档的整个源。

##### 2.6.2、嵌套内部名字和\_source #####

嵌套文档没有\_source字段，因为整个文档\_source是与根文档一 起存储在其\_source字段下。为了仅包含嵌套文档的源，将解析根文 档的源，并且只将嵌套文档的相关bit作为源包含在内部命中中。为每 个匹配的嵌套文档执行此操作会影响执行整个搜索请求所需的时间， 特别是当size和内部命中数的size设置高于默认值时，会付出相对昂 贵的代价。为了避免为获取嵌套内部命中的\_source而解析整个根文 档的\_source，可以禁用返回\_source的功能(“source”:false)， 并且只依赖于doc values字段。示例如下:

PUT test
    {
        
      "mappings": {
        
        "properties": {
        
          "comments": {
        
            "type": "nested"
          }
        }
      }
    }
    
    PUT test/_doc/1?refresh
    {
        
      "title": "Test title",
      "comments": [
        {
        
          "author": "kimchy",
          "text": "comment text"
        },
        {
        
          "author": "nik9000",
          "text": "words words words"
        }
      ]
    }
    
    POST test/_search
    {
        
      "query": {
        
        "nested": {
        
          "path": "comments",
          "query": {
        
            "match": {
        "comments.text" : "words"}
          },
          "inner_hits": {
        
            "_source" : false,
            "docvalue_fields" : [
              "comments.text.keyword"
            ]
          }
        }
      }
    }

{
        
      "took" : 1,
      "timed_out" : false,
      "_shards" : {
        
        "total" : 1,
        "successful" : 1,
        "skipped" : 0,
        "failed" : 0
      },
      "hits" : {
        
        "total" : {
        
          "value" : 1,
          "relation" : "eq"
        },
        "max_score" : 1.0444684,
        "hits" : [
          {
        
            "_index" : "test",
            "_type" : "_doc",
            "_id" : "1",
            "_score" : 1.0444684,
            "_source" : {
        
              "title" : "Test title",
              "comments" : [
                {
        
                  "author" : "kimchy",
                  "text" : "comment text"
                },
                {
        
                  "author" : "nik9000",
                  "text" : "words words words"
                }
              ]
            },
            "inner_hits" : {
        
              "comments" : {
        
                "hits" : {
        
                  "total" : {
        
                    "value" : 1,
                    "relation" : "eq"
                  },
                  "max_score" : 1.0444684,
                  "hits" : [
                    {
        
                      "_index" : "test",
                      "_type" : "_doc",
                      "_id" : "1",
                      "_nested" : {
        
                        "field" : "comments",
                        "offset" : 1
                      },
                      "_score" : 1.0444684,
                      "fields" : {
        
                        "comments.text.keyword" : [
                          "words words words"
                        ]
                      }
                    }
                  ]
                }
              }
            }
          }
        ]
      }
    }

##### 2.6.3、嵌套对象字段和内部命中的层次级别 #####

如果映射具有多层次嵌套对象字段，则可以通过点标记访问每个 级别。例如，如果有一个包含votes嵌套字段的comments嵌套字 段，并且votes应直接与根一起返回，则可以定义以下路径:

PUT test
    {
        
      "mappings": {
        
        "properties": {
        
          "comments": {
        
            "type": "nested",
            "properties": {
        
              "votes": {
        
                "type": "nested"
              }
            }
          }
        }
      }
    }
    
    PUT test/_doc/1?refresh
    {
        
      "title": "Test title",
      "comments": [
        {
        
          "author": "kimchy",
          "text": "comment text",
          "votes": []
        },
        {
        
          "author": "nik9000",
          "text": "words words words",
          "votes": [
            {
        "value": 1 , "voter": "kimchy"},
            {
        "value": -1, "voter": "other"}
          ]
        }
      ]
    }
    
    POST test/_search
    {
        
      "query": {
        
        "nested": {
        
          "path": "comments.votes",
            "query": {
        
              "match": {
        
                "comments.votes.voter": "kimchy"
              }
            },
            "inner_hits" : {
        }
        }
      }
    }

{
        
      "took" : 0,
      "timed_out" : false,
      "_shards" : {
        
        "total" : 1,
        "successful" : 1,
        "skipped" : 0,
        "failed" : 0
      },
      "hits" : {
        
        "total" : {
        
          "value" : 1,
          "relation" : "eq"
        },
        "max_score" : 0.6931471,
        "hits" : [
          {
        
            "_index" : "test",
            "_type" : "_doc",
            "_id" : "1",
            "_score" : 0.6931471,
            "_source" : {
        
              "title" : "Test title",
              "comments" : [
                {
        
                  "author" : "kimchy",
                  "text" : "comment text",
                  "votes" : [ ]
                },
                {
        
                  "author" : "nik9000",
                  "text" : "words words words",
                  "votes" : [
                    {
        
                      "value" : 1,
                      "voter" : "kimchy"
                    },
                    {
        
                      "value" : -1,
                      "voter" : "other"
                    }
                  ]
                }
              ]
            },
            "inner_hits" : {
        
              "comments.votes" : {
        
                "hits" : {
        
                  "total" : {
        
                    "value" : 1,
                    "relation" : "eq"
                  },
                  "max_score" : 0.6931471,
                  "hits" : [
                    {
        
                      "_index" : "test",
                      "_type" : "_doc",
                      "_id" : "1",
                      "_nested" : {
        
                        "field" : "comments",
                        "offset" : 1,
                        "_nested" : {
        
                          "field" : "votes",
                          "offset" : 0
                        }
                      },
                      "_score" : 0.6931471,
                      "_source" : {
        
                        "voter" : "kimchy",
                        "value" : 1
                      }
                    }
                  ]
                }
              }
            }
          }
        ]
      }
    }

##### 2.6.4、父子嵌套 #####

父/子inner\_hits可用于包括父或子对象，示例如下:

PUT test
    {
        
      "mappings": {
        
        "properties": {
        
          "my_join_field": {
        
            "type": "join",
            "relations": {
        
              "my_parent": "my_child"
            }
          }
        }
      }
    }
    
    PUT test/_doc/1?refresh
    {
        
      "number": 1,
      "my_join_field": "my_parent"
    }
    
    PUT test/_doc/2?routing=1&refresh
    {
        
      "number": 1,
      "my_join_field": {
        
        "name": "my_child",
        "parent": "1"
      }
    }
    
    POST test/_search
    {
        
      "query": {
        
        "has_child": {
        
          "type": "my_child",
          "query": {
        
            "match": {
        
              "number": 1
            }
          },
          "inner_hits": {
        }    
        }
      }
    }

{
        
      "took" : 13,
      "timed_out" : false,
      "_shards" : {
        
        "total" : 1,
        "successful" : 1,
        "skipped" : 0,
        "failed" : 0
      },
      "hits" : {
        
        "total" : {
        
          "value" : 1,
          "relation" : "eq"
        },
        "max_score" : 1.0,
        "hits" : [
          {
        
            "_index" : "test",
            "_type" : "_doc",
            "_id" : "1",
            "_score" : 1.0,
            "_source" : {
        
              "number" : 1,
              "my_join_field" : "my_parent"
            },
            "inner_hits" : {
        
              "my_child" : {
        
                "hits" : {
        
                  "total" : {
        
                    "value" : 1,
                    "relation" : "eq"
                  },
                  "max_score" : 1.0,
                  "hits" : [
                    {
        
                      "_index" : "test",
                      "_type" : "_doc",
                      "_id" : "2",
                      "_score" : 1.0,
                      "_routing" : "1",
                      "_source" : {
        
                        "number" : 1,
                        "my_join_field" : {
        
                          "name" : "my_child",
                          "parent" : "1"
                        }
                      }
                    }
                  ]
                }
              }
            }
          }
        ]
      }
    }

#### 2.7、分数值过滤 ####

如下实例中，排除得分\_score低于设定的min\_score的文档:

GET /_search
    {
        
        "min_score": 0.5,
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

> 注意:大多数情况下，这没有多大意义，但它是为高级用例提供 的。

#### 2.8、查询命名 ####

可以为每个查询或过滤起个名字:

GET /_search
    {
        
        "query": {
        
            "bool" : {
        
                "should" : [
                    {
        "match" : {
         "name.first" : {
        "query" : "shay", "_name" : "first"} }},
                    {
        "match" : {
         "name.last" : {
        "query" : "banon", "_name" : "last"} }}
                ],
                "filter" : {
        
                    "terms" : {
        
                        "name.last" : ["banon", "kimchy"],
                        "_name" : "test"
                    }
                }
            }
        }
    }

> 搜索响应将包括matched\_queries。查询和过滤器的命名只对 bool查询有意义。

#### 2.9、post\_filter过滤 ####

在计算聚合之后，post\_filter用来对搜索结果进行二次过滤。其 目的通过如下示例来解释:

PUT /shirts
    {
        
        "mappings": {
        
            "properties": {
        
                "brand": {
         "type": "keyword"},
                "color": {
         "type": "keyword"},
                "model": {
         "type": "keyword"}
            }
        }
    }
    
    PUT /shirts/_doc/1?refresh
    {
        
        "brand": "gucci",
        "color": "red",
        "model": "slim"
    }

假设用户指定了两个过滤器:color:red和brand:gucci。通常 情况下，也可以使用bool查询进行此操作:

GET /shirts/_search
    {
        
      "query": {
        
        "bool": {
        
          "filter": [
            {
         "term": {
         "color": "red"   }},
            {
         "term": {
         "brand": "gucci" }}
          ]
        }
      }
    }

但是，用户可能还需要使用faceted切面导航来显示用户可以单击 的其他选项的列表。也许有一个model字段，允许用户将搜索结果限 制为t-shirts或dress-shirts。  
![在这里插入图片描述][34ccadccd0774f2babce056dac96e352.png]

可以使用如下聚合查询，实现上述功能:

GET /shirts/_search
    {
        
      "query": {
        
        "bool": {
        
          "filter": [
            {
         "term": {
         "color": "red"   }},
            {
         "term": {
         "brand": "gucci" }}
          ]
        }
      },
      "aggs": {
        
        "models": {
        
          "terms": {
         "field": "model" } 
        }
      }
    }

同时，用户可能需要知道有多少其他颜色的Gucci衬衫。如果只 是在颜色字段color上添加一个Term聚合，那么将只返回red对应的结 果，因为查询只返回Gucci的红色衬衫。

相反，用户希望在聚合期间包含所有颜色的衬衫，然后只将 colors过滤器应用于搜索结果。这是post\_filter过滤器的目的:

GET /shirts/_search
    {
        
      "query": {
        
        "bool": {
        
          "filter": {
        
            "term": {
         "brand": "gucci" } 
          }
        }
      },
      "aggs": {
        
        "colors": {
        
          "terms": {
         "field": "color" } 
        },
        "color_red": {
        
          "filter": {
        
            "term": {
         "color": "red" } 
          },
          "aggs": {
        
            "models": {
        
              "terms": {
         "field": "model" } 
            }
          }
        }
      },
      "post_filter": {
         
        "term": {
         "color": "red" }
      }
    }

#### 2.10、分片选择（preference） ####

参数preference控制要对其执行搜索的分片的选择机制。默认情 况下，Elasticsearch以未指定的顺序从可用的分片中进行选择。但 是，有时可能需要尝试将某些搜索路由到特定的分片副本集，以更好 地利用每个副本的缓存。

preference是一个查询字符串参数，可以设置为如下参数:

*  **\_only\_local**：该操作将仅在接受请求的本地节点的分片上执 行。
 *  **\_local**：优先选择本地的分片，本地没有对应分片或对应分 片不可用时再路由到其他分片。
 *  **\_prefer\_nodes**：abc，xyz:如果可能，该操作将在具有提 供的节点ID之一的节点上执行(本例中为abc或xyz)。如果 在多个选定节点上存在合适的分片副本，则这些副本之间的 首选顺序不确定。指定的ID不满足时会路由到其他分片。
 *  **\_shards**：2，3:将操作限制在为指定的分片，本例中为2 和3。此首选项可以与其他首选项组合，但必须首先配置: \_shards:2，3\_u local。
 *  **\_only\_nodes**：abc\*，x\*yz，…:将操作限制到根据节点规 范指定的节点。如果在多个选定节点上存在合适的分片副 本，则这些副本之间的首选顺序不确定。

> 在实际生产环境中用得最多的是\_local，可以节省一定的网络开 销。

#### 2.11、重排序 ####

重新排序有助于提高检索结果的精度，只需重新排序顶部(例如 100-500)文档，使用二级(通常更昂贵)算法，而不是将昂贵的算 法应用于索引中的所有文档。

在每个分片返回其结果给协调节点之前，就会执行重排序 (rescore)请求。

目前，rescore API只有一个实现:query rescorer，它使用查询 来调整评分。在未来，可能会有其他的实现方式。

如果在重排序查询rescore中提供了显式排序，则将引发错误。既 然重排序，就不能再自定义排序。

当向用户显示分页时，不应该在单步浏览每个页面时更改窗口大 小window\_size(通过传递不同的值)，因为这样会改变顶部命中， 导致结果在用户单步浏览页面时发生令人困惑的移动(结果重复或缺 少某些文档)。

查询重新排序器(query rescorer)仅对查询和post\_filter筛选 阶段返回的前k个结果执行二次查询。每个分片上要检查的文档数可 以由window\_size参数控制，该参数默认为10。

默认情况下，原始查询和重排序查询的分数是线性组合的，以生 成每个文档的最终分数。原始查询和重排序查询的相对重要性可以分 别 用 查 询 权 重 query\_weight 和 重 排 序 查 询 权 重 rescore\_query\_weight来控制。两者都默认为1。下面是一个具体示 例:

POST /_search
    {
        
       "query" : {
        
          "match" : {
        
             "message" : {
        
                "operator" : "or",
                "query" : "the quick brown"
             }
          }
       },
       "rescore" : {
        
          "window_size" : 50,
          "query" : {
        
             "rescore_query" : {
        
                "match_phrase" : {
        
                   "message" : {
        
                      "query" : "the quick brown",
                      "slop" : 2
                   }
                }
             },
             "query_weight" : 0.7,
             "rescore_query_weight" : 1.2
          }
       }
    }

score\_mode控制分数的组合方式，支持以下模式:

*  total:加总原始查询和重排序查询的分数，这是默认方式。
 *  multiply:原始分数乘以重排序查询分数，适用于函数查询 的重排序。
 *  avg:原始查询和重排序查询的分数取平均值。
 *  max:原始查询和重排序查询的分数取二者的最大值。
 *  min:原始查询和重排序查询的分数取二者的最小值。

下面示例按顺序执行多个重排序查询:

POST /_search
    {
        
       "query" : {
        
          "match" : {
        
             "message" : {
        
                "operator" : "or",
                "query" : "the quick brown"
             }
          }
       },
       "rescore" : [ {
        
          "window_size" : 100,
          "query" : {
        
             "rescore_query" : {
        
                "match_phrase" : {
        
                   "message" : {
        
                      "query" : "the quick brown",
                      "slop" : 2
                   }
                }
             },
             "query_weight" : 0.7,
             "rescore_query_weight" : 1.2
          }
       }, {
        
          "window_size" : 10,
          "query" : {
        
             "score_mode": "multiply",
             "rescore_query" : {
        
                "function_score" : {
        
                   "script_score": {
        
                      "script": {
        
                        "source": "Math.log10(doc.likes.value + 2)"
                      }
                   }
                }
             }
          }
       } ]
    }

首先第一个query获取查询结果，然后第二个query得到第一个 query的结果。第二个rescore将“看到”第一个rescore所做的排 序，因此可以使用第一个rescore上的大窗口将文档拉到第二个 rescore的较小窗口中。

#### 2.12、脚本字段 ####

允许为每次命中返回脚本(script)计算值(基于不同字段)， 例如:

GET /_search
    {
        
        "query" : {
        
            "match_all": {
        }
        },
        "script_fields" : {
        
            "test1" : {
        
                "script" : {
        
                    "lang": "painless",
                    "source": "doc['price'].value * 2"
                }
            },
            "test2" : {
        
                "script" : {
        
                    "lang": "painless",
                    "source": "doc['price'].value * params.factor",
                    "params" : {
        
                        "factor"  : 2.0
                    }
                }
            }
        }
    }

脚本字段可以处理未存储的字段，并允许返回自定义值(脚本的 计算值)。

脚 本 字 段 还 可 以 访 问 实 际 的 \_source 文 档 ， 并 使 用 params\[‘\_source’\]从中提取要返回的特定元素。下面是一个例子:

GET /_search
    {
        
        "query" : {
        
            "match_all": {
        }
        },
        "script_fields" : {
        
            "test1" : {
        
                "script" : "params['_source']['message']"
            }
        }
    }

理解doc\[‘my\_field’\].value和params\[‘\_source’\]\[‘my\_field’\]之间 的区别很重要。本节第一个示例，使用doc关键字，将导致该字段的 Term被加载到内存(缓存)，致使更快的执行速度，但会造成更多的 内存消耗。另外，doc\[…\]表示法只允许简单值字段(不能从中返回 JSON对象)，并且只对非分析字段或基于单Term的字段有意义。但 是，如果可能，使用doc仍然是从文档中访问值的推荐方法，因为每 次使用\_source时都必须加载和分析，导致使用\_source非常慢。

#### 2.13、滚动查询 ####

当搜索请求返回单个“页面”的结果时，可以使用滚动查询 (scroll)API从单个搜索请求中检索大量结果(甚至是所有结果)， 这与在传统数据库中使用游标的方式非常相似。

滚动不适用于实时用户请求，而适用于处理大量数据，例如为了 将一个索引的内容重新索引到具有不同配置的新索引中。

从滚动请求返回的结果反映了在发出初始搜索请求时索引的状 态，如及时快照。对文档的后续更改(索引、更新或删除)只会影响 以后的搜索请求。

为了使用滚动搜索功能，初始搜索请求应该在查询字符串中指定 scroll参数，该参数告诉Elasticsearch“搜索上下文”应保持活动多长时间，例如scroll=1m。示例如下:

POST /twitter/_search?scroll=1m
    {
        
        "size": 100,
        "query": {
        
            "match" : {
        
                "title" : "elasticsearch"
            }
        }
    }

上述请求的结果包括一个\_scroll\_id，它应该传递给scroll API， 以便检索下一批结果:

POST /_search/scroll 
    {
        
        "scroll" : "1m", 
        "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==" 
    }

上述示例中，scroll参数告诉Elasticsearch将搜索上下文再保持 活跃时间1m。scroll\_id参数是上一次查询的返回值。

size参数用来配置每批结果返回的最大命中数。对scroll API的每 次调用都会返回下一批结果，直到没有更多的结果可以返回，即hits 数组为空。

初始搜索请求和随后的每个滚动请求都返回一个\_scroll\_id。虽 然\_scroll\_id可能在请求之间发生变化，但它并不总是变化。在任何 情况下，只应使用最近收到的\_scroll\_id。

如果请求指定聚合，则只有初始搜索响应将包含聚合结果。

当排序顺序为\_doc时，滚动请求会进行优化。如果需要迭代所有 文档，不管顺序如何，这都是最有效的选项，示例如下:

GET /_search?scroll=1m
    {
        
      "sort": [
        "_doc"
      ]
    }

##### 2.13.1、保持搜索上下文处于活跃状态 #####

滚动搜索请求可返回初始搜索请求匹配的所有文档。它忽略对这 些文档的任何后续更改，搜索上下文跟踪Elasticsearch返回正确文 档所需的所有信息。搜索上下文由初始请求创建，并由后续请求保持 活跃性。

滚动参数scroll(传递给搜索请求和每个滚动请求)告诉 Elasticsearch应该保持搜索上下文活动多长时间。它的值(例如1分 钟)不需要足够长的时间来处理所有数据，只需要足够长的时间来处 理前一批结果，因为每个scroll请求(带有scroll参数)会设置一个新 的到期时间。如果scroll请求没有传递参数scroll，那么搜索上下文将 作为滚动请求的一部分被释放。

通常，后台合并过程通过合并较小的段来优化索引，从而创建新 的较大的段。一旦不再需要较小的段，它们就会被删除。此过程在 scroll查询期间也是正常执行的，但打开的搜索上下文会阻止删除旧 段，因为它们仍在使用中。

此外，如果某个段包含已删除或更新的文档，则搜索上下文必须 跟踪该段中的每个文档在初始搜索请求时是否处于活动状态。如果索 引上有许多打开的滚动查询，并且这些查询会受到正在进行的删除或 更新的影响，请确保节点具有足够的堆空间。

可以使用如下方式检查打开了多少搜索上下文:

GET /_nodes/stats/indices/search

##### 2.13.2、清理搜索上下文 #####

当超过scroll参数设置的超时时间时，搜索上下文将自动删除。 但是，正常情况下保持搜索上下文是有成本的，因此当滚动不再使用 时，应明确清除，示例如下:

DELETE /_search/scroll
    {
        
        "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="
    }

也可以一次清除多个搜索上下文:

DELETE /_search/scroll
    {
        
        "scroll_id" : [
          "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==",
          "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAABFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAAAxZrUllkUVlCa1NqNmRMaUhiQlZkMWFBAAAAAAAAAAIWa1JZZFFZQmtTajZkTGlIYkJWZDFhQQAAAAAAAAAFFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAABBZrUllkUVlCa1NqNmRMaUhiQlZkMWFB"
        ]
    }

要清除所有搜索上下文，可以使用\_all参数:

DELETE /_search/scroll/_all

scroll\_id可以作为查询字符串参数或在请求主体中传递。可以将 用逗号分隔的多个滚动ID传递:

DELETE /_search/scroll/DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==,DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAABFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAAAxZrUllkUVlCa1NqNmRMaUhiQlZkMWFBAAAAAAAAAAIWa1JZZFFZQmtTajZkTGlIYkJWZDFhQQAAAAAAAAAFFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAABBZrUllkUVlCa1NqNmRMaUhiQlZkMWFB

##### 2.13.3、切片 #####

对于返回大量文档的滚动查询，可以将滚动拆分为多个可独立使 用的切片，来并行执行整个查询过程，示例如下:

GET /twitter/_search?scroll=1m
    {
        
        "slice": {
        
            "id": 0, 
            "max": 2 
        },
        "query": {
        
            "match" : {
        
                "title" : "elasticsearch"
            }
        }
    }
    GET /twitter/_search?scroll=1m
    {
        
        "slice": {
        
            "id": 1,
            "max": 2
        },
        "query": {
        
            "match" : {
        
                "title" : "elasticsearch"
            }
        }
    }

上述示例中，第一个请求的结果属于第一个切片(ID:0)的文 档，第二个请求的结果属于第二个切片的文档。由于最大切片数设置 为2，因此两个请求的结果的并集相当于不进行切片的滚动查询的结 果。默认情况下，首先在分片上完成分割，然后在每个分片上使用带 有以下公式的\_id字段进行切片:

slice(doc) = floorMod(hashCode(doc._id),max)

例如，如果分片数量等于2，并且用户请求4个切片，则切片0和2 被分配给第一个分片，切片1和3被分配到第二个分片。

每个滚动是独立的，可以并行处理。

如果切片数量大于分片数量，则切片过滤器在第一次调用时速度 非常慢，它的复杂性为O(n)，并且内存成本等于每个切片的 NBit，其中N是分片中的文档总数。在几次调用之后，应该会缓存过 滤器，随后的调用就会更快，但是应该限制并行执行的切片查询的数 量，以避免内存爆炸。

为了完全避免这种开销，可以使用另一个字段的doc\_values进行 切片，但用户必须确保该字段具有以下属性:

*  该字段是数字。
 *  在该字段上启用doc\_values。
 *  每个文档的该字段都应该是单值。如果一个文档的指定字段 有多个值，则使用第一个值。
 *  创建文档时，每个文档的值都应设置一次，并且从不更新。 这样可以确保每个切片都得到确定的结果。
 *  字段的基数应该很高，这样可以确保每个切片获得大致相同 数量的文档。

默认情况下，每个滚动请求允许的最大切片数限制为1024。可以 更新index.max\_slices\_per\_scroll设置以绕过此限制。

#### 2.14、search\_after参数 ####

结果的分页可以通过使用from和size来完成，但当达到深度分页 时，开销会变得难以控制。index.max\_result\_window默认值为10 000，是一种保护措施，搜索请求占用堆内存和时间，与from+size 大小成比例。建议使用scroll API进行深度分页，但滚动上下文成本 高昂，不建议将其用于实时用户请求。search\_after参数通过提供活 动光标来绕过这个问题。其思想是使用上一页的结果来帮助检索下一 页。

假设检索第一页的查询如下所示:

GET twitter/_search
    {
        
        "size": 10,
        "query": {
        
            "match" : {
        
                "title" : "elasticsearch"
            }
        },
        "sort": [
            {
        "date": "asc"},
            {
        "tie_breaker_id": "asc"}      
        ]
    }

上述示例代码中，tie\_breaker\_id是\_id字段的副本，已启用 doc\_values。

每个文档应使用具有唯一值的字段来排序。否则，具有相同排序 值的文档的排序顺序将未定义，并可能导致结果丢失或重复。\_id字段 对于每个文档都有唯一的值，但不建议将其直接用作排序的决定因 子。注意，tiebreaker要查找完全或部分匹配tiebreaker(排序的决 定值)提供的值的第一个文档。因此，如果一个文档的tiebreaker值 为654 323，并且在其后面搜索654，它仍然会匹配该文档并返回在 其之后找到的结果。doc\_values在这个字段上被禁用，因此对它进行 排序需要在内存中加载大量数据。相反，建议在启用了doc\_values的 另一个字段中复制id字段的内容，并使用此新字段作为排序字段。

上述请求的结果包括每个文档的sort values。这些sort values 可以与search\_after参数一起使用，以在结果列表中的任何文档“之 后”开始返回结果。例如，可以使用最后一个文档的排序值sort values，然后将其传递给搜索者，以便检索下一页的结果，示例如 下:

GET twitter/_search
    {
        
        "size": 10,
        "query": {
        
            "match" : {
        
                "title" : "elasticsearch"
            }
        },
        "search_after": [1463538857, "654323"],
        "sort": [
            {
        "date": "asc"},
            {
        "tie_breaker_id": "asc"}
        ]
    }

参数from必须设置为0(或-1)。

search\_after不是自由跳转到随机页面的解决方案，而是并行滚 动许多查询。它与scroll API非常相似，但与之不同的是， search\_after参数是无状态的，它总是根据搜索者的最新版本进行解析。因此，在执行过程中，排序顺序可能会根据索引的更新或删除而 改变。

#### 2.15、搜索类型 ####

在进行分布式搜索时，会执行不同的路径。分布式搜索操作需要 把请求分发到所有相关的分片上，然后将所有结果收集回到协调节 点。当执行分发和收集时，有几种方法可以做到这一点，特别是使用 搜索引擎时。

执行分布式搜索时的一个问题是从每个分片中检索多少结果。例 如，如果有10个分片，第一个分片可能包含从0到10的最相关结果， 其他分片的结果排名低于它。因此，在执行请求时，需要从所有分片 中都获取从0到10的结果，对它们进行排序，然后返回结果，这样才 可以确保结果的正确性。

另一个与搜索引擎相关的问题是，每个分片都是独立存在的。当 对特定分片执行查询时，它不考虑来自其他分片的Term频率和向量信 息。如果我们想要支持精确的排名，需要首先从所有分片收集Term频 率来计算全局Term频率，然后使用这些全局频率对每个分片执行查 询。

此外，由于需要对结果进行排序、返回大型文档集，甚至滚动 它，同时保持正确的排序行为可能是一个非常昂贵的操作。对于大型 结果集的scroll操作，如果返回文档的顺序不重要，最好按\_doc排 序。

Elasticsearch是非常灵活的，它允许根据每个搜索请求控制要 执行的搜索类型(search\_type)。可以通过在查询字符串中设置 search\_type参数来配置搜索类型，其中类型有如下两种:

*  query\_then\_fetch(默认值):请求分两个阶段处理。在第 一阶段，查询被转发到所有相关的分片，每个分片执行搜索 并生成一个结果的排序列表。每个分片只返回足够的信息给 协调节点(排序过的文档ID和排序需要的相关字段)，以允 许它合并并将分片级别的结果重新排序。

在第二阶段中，协调节点只从相关的分片请求文档内容(以及高 亮显示的片段，如果有)。

*  dfs\_query\_then\_fetch : 第 二 阶 段 与 query\_then\_fetch 相 同，但在初始请求分发执行阶段是不同的，该阶段进行并计 算分布式Term频率，以便更准确地评分。

#### 2.16、排序 ####

可以按特定一个或多个字段对结果排序。排序是在每个字段级别 上定义的，\_score用于按得分排序，以及按索引顺序排序的\_doc。  
假设以下索引映射:

PUT /my_index
    {
        
        "mappings": {
        
            "properties": {
        
                "post_date": {
         "type": "date" },
                "user": {
        
                    "type": "keyword"
                },
                "name": {
        
                    "type": "keyword"
                },
                "age": {
         "type": "integer" }
            }
        }
    }

如下示例，返回结果按多个字段进行排序，与SQL语言中的 order by功能类似:

GET /my_index/_search
    {
        
        "sort" : [
            {
         "post_date" : {
        "order" : "asc"}},
            "user",
            {
         "name" : "desc" },
            {
         "age" : "desc" },
            "_score"
        ],
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

除了最准确的排序(因为\_doc是唯一值，排序准确)顺序之外， \_doc很少被实际应用。因此，如果不关心返回文档的顺序，那么应该 按\_doc排序，这在滚动查询时尤其有用。

##### 2.16.1、排序方式 #####

排序方式有两种:asc，升序;desc，降序。与SQL语言是相同 的。

##### 2.16.2、多值字段排序模式 #####

Elasticsearch支持按数组或多值字段排序。模式选项mode控制 对文档进行排序的值，它有以下几种值:

*  **min**：数组或多值字段的最小值作为排序值。
 *  **max**：数组或多值字段的最大值作为排序值。
 *  **sum**：数组或多值字段的和作为排序值。
 *  **avg**：数组或多值字段的平均值作为排序值。
 *  **median**：数组或多值字段的中位数作为排序值。

以升序排序的默认排序模式是min，选择最小值作为排序值。按 降序排列的默认排序模式是max，取最大值作为排序值。

在下面的示例中，字段price每个文档有多个价格。在这种情况 下，结果将按每个文档的平均价格升序排序。

PUT /my_index/_doc/1?refresh
    {
        
       "product": "chocolate",
       "price": [20, 4]
    }
    
    POST /_search
    {
        
       "query" : {
        
          "term" : {
         "product" : "chocolate" }
       },
       "sort" : [
          {
        "price" : {
        "order" : "asc", "mode" : "avg"}}
       ]
    }

##### 2.16.3、嵌套对象的排序 #####

Elasticsearch还支持按一个或多个嵌套对象中的字段排序。按 嵌套字段的排序支持一个nested属性，该属性具有以下选项:

*  **path**：定义要用来排序的嵌套对象字段。实际排序字段必须 是此嵌套对象内的直接字段(内部不能再嵌套)。按嵌套字 段排序时，此字段是必需的。
 *  **filter**：常见的情况是在嵌套的过滤器或查询中重复查询/过 滤。
 *  **max\_children**：选择排序值时每个根文档要考虑的最大子 级数，默认为无限制。
 *  **nested**：与顶层嵌套相同，但适用于当前嵌套对象中的另一 个嵌套路径。

在下面的示例中，offer是一个嵌套类型的字段。需要指定嵌套路 径path，否则Elasticsearch不知道需要获取什么嵌套级别的排序 值。

POST /_search
    {
        
       "query" : {
        
          "term" : {
         "product" : "chocolate" }
       },
       "sort" : [
           {
        
              "offer.price" : {
        
                 "mode" :  "avg",
                 "order" : "asc",
                 "nested": {
        
                    "path": "offer",
                    "filter": {
        
                       "term" : {
         "offer.color" : "blue" }
                    }
                 }
              }
           }
        ]
    }

在下面的示例中，父字段和子字段的类型为嵌套。嵌套的路径需 要在每个级别上指定，否则，Elasticsearch不知道需要捕获哪个嵌 套级别的排序值。

POST /_search
    {
        
       "query": {
        
          "nested": {
        
             "path": "parent",
             "query": {
        
                "bool": {
        
                    "must": {
        "range": {
        "parent.age": {
        "gte": 21}}},
                    "filter": {
        
                        "nested": {
        
                            "path": "parent.child",
                            "query": {
        "match": {
        "parent.child.name": "matt"}}
                        }
                    }
                }
             }
          }
       },
       "sort" : [
          {
        
             "parent.child.age" : {
        
                "mode" :  "min",
                "order" : "asc",
                "nested": {
        
                   "path": "parent",
                   "filter": {
        
                      "range": {
        "parent.age": {
        "gte": 21}}
                   },
                   "nested": {
        
                      "path": "parent.child",
                      "filter": {
        
                         "match": {
        "parent.child.name": "matt"}
                      }
                   }
                }
             }
          }
       ]
    }

##### 2.16.4、缺失值的处理 #####

missing参数指定如何处理缺少排序字段的文档。可以将 missing的值设置为\_last、\_first或自定义值(将用作缺失排序字段的文档的排序值)，默认值为\_last。示例如下:

GET /_search
    {
        
        "sort" : [
            {
         "price" : {
        "missing" : "_last"} }
        ],
        "query" : {
        
            "term" : {
         "product" : "chocolate" }
        }
    }

默认情况下，排序字段如果没有与字段关联的映射，则搜索请求 将失败。unmapped\_type选项允许忽略没有映射的字段，不按它们 排序。此参数的值用于确定要排序字段的映射类型，即自定义排序字 段的数据类型。下面是一个如何使用它的示例:

GET /_search
    {
        
        "sort" : [
            {
         "price" : {
        "unmapped_type" : "long"} }
        ],
        "query" : {
        
            "term" : {
         "product" : "chocolate" }
        }
    }

如果查询的任何索引没有价格(price)映射类型，那么 Elasticsearch将当作long类型的映射来处理long，该索引中的所有 文档都没有该字段的值。

##### 2.16.5、地理距离排序 #####

可以按地理距离(geo)\_geo\_distance排序。下面是一个例子， 假设pin.location是geo\_point类型的字段:

GET /_search
    {
        
        "sort" : [
            {
        
                "_geo_distance" : {
        
                    "pin.location" : [-70, 40],
                    "order" : "asc",
                    "unit" : "km",
                    "mode" : "min",
                    "distance_type" : "arc",
                    "ignore_unmapped": true
                }
            }
        ],
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

各参数的含义如下:

*  **distance\_type**：如何计算距离。可以是arc(默认)，也可 以是plane(更快，但在长距离和接近极点时不准确)。
 *  **mode**：如果一个场景有几个地理点(也就是多值)，该怎 么办?默认情况下，升序排序时考虑最短距离，降序排序时 考虑最长距离。支持的值包括min、max、median和avg。
 *  **unit**：排序字段值的单位，默认是m(米)。
 *  **ignore\_unmapped**：上面已经讲过了，排序字段没有类型 该怎么处理。

地理距离排序不支持可配置的默认值:当文档没有用于距离计算 的字段值时，该距离将始终被视为无穷大(Infinity)。  
地理距离排序支持多种坐标格式，如下是应用示例。

###### 2.16.5.1、JSON经纬度格式 ######

GET /_search
    {
        
        "sort" : [
            {
        
                "_geo_distance" : {
        
                    "pin.location" : {
        
                        "lat" : 40,
                        "lon" : -70
                    },
                    "order" : "asc",
                    "unit" : "km"
                }
            }
        ],
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

###### 2.16.5.2、逗号分隔格式 ######

GET /_search
    {
        
        "sort" : [
            {
        
                "_geo_distance" : {
        
                    "pin.location" : "40,-70",
                    "order" : "asc",
                    "unit" : "km"
                }
            }
        ],
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

###### 2.16.5.3、pin码格式 ######

GET /_search
    {
        
        "sort" : [
            {
        
                "_geo_distance" : {
        
                    "pin.location" : "drm3btev3e86",
                    "order" : "asc",
                    "unit" : "km"
                }
            }
        ],
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

###### 2.16.5.4、数组格式 ######

GET /_search
    {
        
        "sort" : [
            {
        
                "_geo_distance" : {
        
                    "pin.location" : [-70, 40],
                    "order" : "asc",
                    "unit" : "km"
                }
            }
        ],
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

###### 2.16.5.5、两点距离格式 ######

GET /_search
    {
        
        "sort" : [
            {
        
                "_geo_distance" : {
        
                    "pin.location" : [[-70, 40], [-71, 42]],
                    "order" : "asc",
                    "unit" : "km"
                }
            }
        ],
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

##### 2.16.6、自定义脚本排序 #####

可以通过自定义的脚本的计算结果进行排序，示例如下:

GET /_search
    {
        
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        },
        "sort" : {
        
            "_script" : {
        
                "type" : "number",
                "script" : {
        
                    "lang": "painless",
                    "source": "doc['field_name'].value * params.factor",
                    "params" : {
        
                        "factor" : 1.1
                    }
                },
                "order" : "asc"
            }
        }
    }

#### 2.17、\_source字段过滤 ####

可以控制每个命中文档的\_source字段的返回方式。默认情况 下，操作将返回\_source字段的内容，除非使用了stored\_fields参数 或禁用了\_source字段。

可以使用\_source参数关闭\_source字段检索，要禁用\_source字 段返回，设置为false，示例如下:

GET /_search
    {
        
    	"_source": false,
    	"query": {
        
    		"term":{
        "user":"kimchy"}
    	}
    }

\_source还接受一个或多个通配符模式来控制应返回\_source的哪 些部分，当然也可以不包括通配符即准确指定返回的字段，下面是两 个示例:

GET /_search
    {
        
    	"_source": "obj.*",
    	"query": {
        
    		"term":{
        "user":"kimchy"}
    	}
    }
    
    GET /_search
    {
        
    	"_source": ["obj1.*","obj2.*"]
    	"query": {
        
    		"term":{
        "user":"kimchy"}
    	}
    }

如果需要更完全的控制，可以指定includes和excludes模式:

GET /_search
    {
        
    	"_source": {
        
    		"includes":["obj1.*","obj2.*"],
    		"excludes":["*.description"]
    	}
    	"query": {
        
    		"term":{
        "user":"kimchy"}
    	}
    }

#### 2.18、存储字段 ####

存储字段指的是建立索引映射，store设置为true的字段(默认是 false)，通常不建议使用(增加内存开销)。

stored\_fields参数控制存储字段的返回，建议使用source来选择 要返回的原始文档的哪些字段。

允许有选择地为搜索命中的文档加载特定的存储字段，示例如 下:

GET /_search
    {
        
        "stored_fields" : ["user", "postDate"],
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

\*可用于加载文档中的所有存储字段。  
stored\_fields为空数组将只返回每次命中的\_id和\_type字段，例 如:

GET /_search
    {
        
        "stored_fields" : [],
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

如果请求的字段存储映射设置为false，则将忽略这些字段。

从文档本身获取的存储字段值始终作为数组返回。相反，像路由 \_routing这样的元数据字段永远不会作为数组返回。此外，只能通过 字段选项返回叶字段，不能返回对象字段，这样的请求将失败。

脚本字段也可以自动检测并用作字段，因此可以使用 \_source.obj1.field1之类的内容，但不推荐，因为obj1.field1是更好 的选择。

下面的示例禁用stored\_fields:

GET /_search
    {
        
        "stored_fields": "_none_",
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

#### 2.19、total返回值详解（track\_total\_hits） ####

通常，要准确计算总命中数，必须访问所有匹配项，这对于匹配 大量文档的查询来说代价高昂。track\_total\_hits参数允许控制应如 何跟踪命中总数(控制total的准确度)。track\_total\_hits默认设置 为10 000，这意味着请求命中数在10 000以内，total计数是准确 的，total.relation值是eq。如果请求命中数大于10 000时，计数是不准确的，此时total的值是10 000，total.relation值是gte。如果不 需要准确的命中总数，这种设计可以加速查询。

当track\_total\_hits设置为true时，搜索响应返回的命中总数始 终是准确的(total.relation始终等于eq)。搜索响应中total对象中 返回的total.relation将决定total.value是否准确。gte的值表示 total.value匹配查询的总命中数的下限，eq的值表示total.value是准 确的计数。

通过如下示例，再来分析:

GET twitter/_search
    {
        
        "track_total_hits": true,
         "query": {
        
            "match" : {
        
                "message" : "Elasticsearch"
            }
         }
    }

{
        
        "_shards": ...
        "timed_out": false,
        "took": 100,
        "hits": {
        
            "max_score": 1.0,
            "total" : {
        
                "value": 2048,    
                "relation": "eq"  
            },
            "hits": ...
        }
    }

也可以将track\_total\_hits设置为整数。例如，以下查询将准确 跟踪与查询匹配的命中总数，最多100个文档，也就是命中文档数低 于100时，是准确的，高于100时是不准确的(total.relation值是 gte):

GET twitter/_search
    {
        
        "track_total_hits": 100,
         "query": {
        
            "match" : {
        
                "message" : "Elasticsearch"
            }
         }
    }

如果不需要跟踪命中总数，可以通过将此选项设置为false来改进 查询时间:

GET twitter/_search
    {
        
        "track_total_hits": false,
         "query": {
        
            "match" : {
        
                "message" : "Elasticsearch"
            }
         }
    }

#### 2.20、版本控制（\_version） ####

Elasticsearch中的版本功能在并发更新文档时，用来处理冲突 的机制。Elasticsearch采用的是乐观并发控制机制。这种方法假定 冲突是不可能发生的，所以不会阻塞正在尝试的操作。然而，如果源 数据在读写当中被修改，更新将会失败。应用程序接下来将决定该如 何解决冲突。例如，可以获取新的数据，重试更新或者将相关情况报 告给用户。

Elasticsearch是分布式的，当文档创建、更新、删除时，新版 本的文档必须复制到集群中其他节点，同时，Elasticsearch也是异 步和并发的。这就意味着这些复制请求被并行发送，并且到达目的地 时也许顺序是乱的(老版本可能在新版本之后到达)。 Elasticsearch需要一种方法确保文档的旧版本不会覆盖新的版本。 Elasticsearch利用\_version(版本号)的方式来确保应用中相互冲 突的变更不会导致数据丢失。需要修改数据时，需要指定想要修改文 档的version号，如果该版本不是当前版本号，请求将会失败。

可以通过如下方式返回文档的版本信息:

GET /bank/_search
    {
        
      "version": true,
      "query": {
        
        "term": {
        
          "city.keyword": {
        
            "value": "Orick"
          }
        }
      }
    }

### 3、返回索引分片信息（\_search\_shards） ###

\_search\_shards API返回将针对其执行搜索请求的索引和分片 信息。这可以为解决问题或使用路由和分片首选项计划优化提供有用 的反馈。

//语法
 GET /<index>/_search_shards

示例：

GET /twitter/_search_shards

{
        
      "nodes" : {
        
        "Cc6ARDA6TY-poOdtxvsA6g" : {
        
          "name" : "zhangchenglongdeMacBook-Pro.local",
          "ephemeral_id" : "YekwqhksTmazQePnvw1-YQ",
          "transport_address" : "127.0.0.1:9300",
          "attributes" : {
        
            "ml.machine_memory" : "17179869184",
            "xpack.installed" : "true",
            "transform.node" : "true",
            "ml.max_open_jobs" : "512",
            "ml.max_jvm_size" : "1037959168"
          },
          "roles" : [
            "data",
            "data_cold",
            "data_content",
            "data_frozen",
            "data_hot",
            "data_warm",
            "ingest",
            "master",
            "ml",
            "remote_cluster_client",
            "transform"
          ]
        }
      },
      "indices" : {
        
        "twitter" : {
         }
      },
      "shards" : [
        [
          {
        
            "state" : "STARTED",
            "primary" : true,
            "node" : "Cc6ARDA6TY-poOdtxvsA6g",
            "relocating_node" : null,
            "shard" : 0,
            "index" : "twitter",
            "allocation_id" : {
        
              "id" : "3OsEagVpRFifBrs-baJTzA"
            }
          }
        ]
      ]
    }

也可以在请求中带有路由值:

GET /twitter/_search_shards?routing=foo,bar

支持的参数如下：

*  **routing**：一个逗号分隔的路由值列表，在确定请求将分发哪个分片执行时 用到这些值。
 *  **preference**：这个是控制优先在哪些分片上执行请求，在上面的章节已经进行 过讲解。
 *  **local**：一个布尔值，控制是否在本地读取集群状态，以确定在何处分配 分片，而不是使用主节点的集群状态。

### 4、Count API ###

Count API可以轻量级执行查询并获取该查询的匹配文档数。它 可以跨一个或多个索引执行。可以使用简单查询字符串作为参数提供 查询，也可以使用请求正文中定义的查询DSL。

//语法
 GET /<index>/_count

示例：

PUT /twitter/_doc/1?refresh
    {
        
        "user": "kimchy"
    }
    
    GET /twitter/_count?q=user:kimchy
    
    GET /twitter/_count
    {
        
        "query" : {
        
            "term" : {
         "user" : "kimchy" }
        }
    }

### 5、Validate API ###

Validate API允许用户在不执行查询的情况下验证查询的合法 性。

//语法
 GET /<index>/_validate/<query>

示例：

PUT twitter/_bulk?refresh
    {
        "index":{
        "_id":1}}
    {
        "user" : "kimchy", "post_date" : "2009-11-15T14:12:12", "message" : "trying out Elasticsearch"}
    {
        "index":{
        "_id":2}}
    {
        "user" : "kimchi", "post_date" : "2009-11-15T14:12:13", "message" : "My username is similar to @kimchy!"}

发送一个验证查询:

GET twitter/_validate/query?q=user:foo

也可以使用body形式:

GET twitter/_validate/query
    {
        
      "query" : {
        
        "bool" : {
        
          "must" : {
        
            "query_string" : {
        
              "query" : "*:*"
            }
          },
          "filter" : {
        
            "term" : {
         "user" : "kimchy" }
          }
        }
      }
    }

### 6、调试（\_explain） ###

调试API(\_explain)可以查看查询和特定文档计算分数的细 节。无论文档是否匹配特定查询，这都可以提供有用的反馈。必须为 index参数提供单个索引。

//语法
 GET /<index>/_explain/<id> 
 POST /<index>/_explain/<id>

示例：

GET /twitter/_explain/0
    {
        
          "query" : {
        
            "match" : {
         "message" : "elasticsearch" }
          }
    }

{
        
       "_index":"twitter",
       "_type":"_doc",
       "_id":"0",
       "matched":true,
       "explanation":{
        
          "value":1.6943598,
          "description":"weight(message:elasticsearch in 0) [PerFieldSimilarity], result of:",
          "details":[
             {
        
                "value":1.6943598,
                "description":"score(freq=1.0), computed as boost * idf * tf from:",
                "details":[
                   {
        
                      "value":2.2,
                      "description":"boost",
                      "details":[]
                   },
                   {
        
                      "value":1.3862944,
                      "description":"idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:",
                      "details":[
                         {
        
                            "value":1,
                            "description":"n, number of documents containing term",
                            "details":[]
                         },
                         {
        
                            "value":5,
                            "description":"N, total number of documents with field",
                            "details":[]
                         }
                      ]
                   },
                   {
        
                      "value":0.5555556,
                      "description":"tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:",
                      "details":[
                         {
        
                            "value":1.0,
                            "description":"freq, occurrences of term within document",
                            "details":[]
                         },
                         {
        
                            "value":1.2,
                            "description":"k1, term saturation parameter",
                            "details":[]
                         },
                         {
        
                            "value":0.75,
                            "description":"b, length normalization parameter",
                            "details":[]
                         },
                         {
        
                            "value":3.0,
                            "description":"dl, length of field",
                            "details":[]
                         },
                         {
        
                            "value":5.4,
                            "description":"avgdl, average length of field",
                            "details":[]
                         }
                      ]
                   }
                ]
             }
          ]
       }
    }

[00371f4606c9467eb37addd85beda29b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/dec16b3c611c402fb97fc6b810a7b4c4.png
[68bee673ad314849b7fe6ea92f460e6f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/753c6d0b34e84080bf30c698948f5d6f.png
[34ccadccd0774f2babce056dac96e352.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/dda5ddac577e4ffea64ddd1d30cac648.png