Elasticsearch-6-深入Search的运行机制

索引：

第一部分 Query-Then-Fetch
第二部分 相关性算分
第三部分 sorting-doc-values-field
第四部分 分页与遍历
1.fromsize
2.scroll
3.search_after

---

第一部分 Query-Then-Fetch

Search在执行的时候实际上分为两个步骤运作（称为Query-Then-Fetch）：

• Query
• Fetch

Query阶段

1. node3在接收到用户的search请求后，会先进行Query阶段（此时是Coordinating Node的角色）
2. node3在6个主副分片中随机选择3个分片，并发送search request
3. 被选中的3个分片会分别执行查询并排序，返回from+size个文档ID和排序值
4. node3整合3个分片返回的from+size个文档Id，根据排序值排序后选取from到from+size的文档Id

Fetch阶段

node3根据Query阶段获取的文档Id列表去对应的shard上获取文档的详情数据

1. node3向相关的分片发送multi_get 请求
2. 3个分片返回文档详细数据
3. node3拼接返回的结果并返回给客户

 

第二部分 相关性算分

• 相关系算分在shard于shard间是相对独立的，也就意味着同一个term的IDF等值在不同shard上是不同的。文档的相关性算分和它所处的shard相关。
• 在文档数量不多时，会导致相关性算分严重不准的情况发生。

解决方法：

1. 设置分片数为1个，从根本上解决问题，在文档数量不多的时候比如几千万，可以考虑该方案。
2. 使用DFS Query-then-Fetch查询方式

DFS Query-then-Fetch是在拿到所有文档后再从新完整的计算一次相关性算分，耗费更多的cpu和内存，执行性能也比较低下，一般不建议使用。使用方式如下：

 

 

第三部分 排序

ES默认使用相关性算分来排序，如果想改变排序规则可以使用sort，

EXAMPLE 按照出生日期倒序排列：

给定多个排序条件，先按照birth倒序排列，如果birth相同按照相关性得分倒序排列，如果相关系得分也相同那么就按照文档id倒序排：

 

按照字符串排序

比较特殊，因为es有text和keyword类型，针对text类型排序，如果直接使用sort字符串名会报错，要使用keyword

 

排序的过程是指是对字段原始内容排序的过程，这个过程中倒排索引无法发挥作用，需要用到正排索引，也就是通过文档Id和字段可以快速得到字段原始内容。

es对此提供了两种实现方式：

• fielddata默认禁用
• doc value默认禁用，除了text类型

fielddata的启用api：

• 此时字符串是按照分词后的term排序，往往结果很难符合预期
• 一般是在对分词做聚合分析的时候开启
• 可以随时开启或关闭

Doc value默认启用，就可以在创建的时候关闭，明确知道不需要按照这个字段来排序或聚合分析的时候可以关闭，如果后面要再开启doc value需要做reindex操作

可以通过该字段获取fielddata或者doc values中存储的内容

 

第四部分 分页与遍历

使用场景：

1.from/size

这是最常用的分页方案：

• from 指明开始位置
• size 指明获取总数

 

深度分页问题(这就是百度或者google所有不能把页面全部获取出来的原因)：

在数据分片存储的情况下如何获取前1000个文档

• 获取9900-1000的文档时，会在每个分片上都先获取1000个文档，然后再由Coordinating Node聚合所有分片的结果后再排序选取前1000个文档（因为数据分散存储了，Coordinating Node是没有全局的概念的）
• 页数越多，处理文档就越多，占用内存越多，耗时越长。尽量避免深度分页，es通过index.max_result_window限定最多到10000条数据

 

2.scroll

遍历文档集的api，以快照的方式来避免深度分页的问题

• 不能用来做实时搜索，因为数据不是实时的
• 尽量不要使用复杂的sort条件，使用_doc最高效
• 使用稍嫌复杂

Scroll过程：

第一步 发起一个scroll search：

es在收到该请求后会根据查询条件穿件文档Id合集的快照

5m就是快照的有效期，5分钟，超过5分钟就失效了，size是返回的文档数。

第二步 调用scroll search 的 api，获取文档的集合，如下图所示：

不断的迭代调用直到返回hits.hits数组为空时停止

注意：过多的scroll调用会占用大量的内存，可以通过clear api删除过多的快照

 

3.search_after

避免深度分页的性能问题，提供实时的下一页文档获取功能

• 缺点是不能使用from参数，即不能指定页数
• 只能下一页，不能上一页
• 使用简单，性能极高

第一步 正常搜索，但是要制定sort的值，并保证值唯一

第二步 使用上一步最后一个文档的sort值进行查询

执行原理 -> 如何避免深度分页问题？

通过唯一排序值定位将每次要处理的文档数都控制在size内