ES - Search的运行机制

Search执行的时候实际分两个步骤运作的

Query阶段

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

Fetch 阶段

node3根据Query阶段获取的文档Id列表去对应的shard 上获取文档详情数据
- node3向相关的分片发送 multi_get请求
- 3个分片返回文档详细数据
- node3拼接返回的结果并返回给客户

相关性算分问题

相关性算分在 shard 与 shard 间是相互独立的，也就意味着同一个 Term 的 IDF 等值在不同 shard 上是不同的。文档的相关性算分和它所处的 shard 相关
在文档数量不多时，会导致相关性算分严重不准的情况发生（在不同的shard上面）
解决思路有两个:
- 设置分片数为1个，从根本上排除问题，在文档数量不多的时候可以考虑该方案，比如百万到千万级别的文档数量
- 使用DFS Query-then-Fetch查询方式
  - DFSQuery-then-Fetch 是在拿到所有文档后再重新完整的计算一次相关性算分，耗费更多的 cpu 和内存，执行性能也比较低下，一般不建议使用。使用方式如下

排序

es默认会采用相关性算分排序，用户可以通过设定sorting参数来自行设定排序规则

按照字符串排序比较特殊，因为es有 text和 keyword 两种类型，针对 text 类型排序，如下所示:

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

es对此提供了2种实现方式
- fielddata 默认禁用
- doc values 默认启用，除了 text 类型

对比	FieldData	DocValues
创建时机	搜索时即时创建	索引时创建，与倒排索引创建时机一致
创建位置	JVM Heap	磁盘
优点	不会占用额外的磁盘资源	不会占用 Heap 内存
缺点	文档过多时，即时创建会花过多时间，占用过多Heap内存	减慢索引的速度，占用额外的磁盘资源

Fielddata默认是关闭的，可以通过如下api开启︰

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

Doc Values 默认是启用的，可以在创建索引的时候关闭如果后面要再开启 doc values，需要做 reindex 操作作

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

分页与遍历

es提供了3种方式来解决分页与遍历的问题

from/size
scroll
search_after

最常用的分页方案

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

深度分页

深度分页是一个经典的问题：在数据分片存储的情况下如何获取前1000个文档?
- 获取从990~1000的文档时，会在每个分片上都先获取1000个文档，然后再由 Coordinating Node 聚合所有分片的结果后再排序选取前1000个文档
- 页数越深，处理文档越多，占用内存越多，耗时越长。尽量避免深度分页，es 通过 index.max_result_window 限定最多到 10000条数据

Scroll

遍历文档集的 api，以快照的方式来避免深度分页的问题
- 不能用来做实时搜索，因为数据不是实时的
- 尽量不要使用复杂的 sort 条件，使用_doc 最高效
- 使用稍嫌复杂
第一步需要发起1个 scroll search，如下所示
- es 在收到该请求后会根据查询条件创建文档 Id 合集的快照

第二步调用 scroll search 的 api，获取文档集合，如下所示不断迭代调用直到返回 hits.hits 数组为空时停止

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

Search After

避免深度分页的性能问题，提供实时的下一页文档获取功能
- 缺点是不能使用from参数，即不能指定页数
- 只能下一页，不能上一页
- 使用简单
第一步为正常的搜索，但要指定 sort 值，并保证值唯一
第二步为使用上一步最后一个文档的 sort 值进行查询

如何避免深度分页问题 ?

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

类型	场景
From/Size	需要实时获取顶部的部分文档，且需要自由翻页
Scroll	需要全部文档，如导出所有数据的功能
Search_After	需要全部文档，不需要自由翻页