第06章-Search的运行机制

Search 执行的时候实际分两个步骤运作的，即 Query-Then-Fetch

Query 阶段过程：

注意：上述步骤中选取的 3 个分片，必须包含索引的完整数据，即 0, 1, 2 分片必须都有，但是可以是主分片也可以是副本分片

Fetch 阶段过程：

# 二、相关性算分问题

相关性算分在 shard 与 shard 间是相互独立的，也就意味着同一个 Term 的 IDF 等值在不同 shard 上是不同的。文档的相关性算分和它所处的 shard 相关。

在文档数量不多时，会导致相关性算分严重不准的情况发生。

解决思路有两个：

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

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

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

针对 keyword 类型排序，可以返回预期结果：

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

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

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

Doc Values 默认是启用的，可以在创建索引的时候关闭，如果后面要再开启 doc values，需要做 reindex 操作。如果明确知道不会按照某个字段进行排序，可以考虑关闭 doc values，最大限度的加快索引速度，减少磁盘占用。

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

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

最常用的分页方案，from 指明开始位置，size 指明获取总数

深度分页问题

深度分页是一个经典的问题：在数据分片存储的情况下如何获取前 1000 个文档？

获取从 990~1000 的文档时，会在每个分片上都先获取 1000 个文档，然后再由 Coordinating Node 聚合所有分片的结果后再排序选取前 1000 个文档
页数越深，处理文档越多，占用内存越多，耗时越长。尽量避免深度分页，es 通过 index.max result window 限定最多到 10000 条数据

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

使用步骤：

第一步需要发起一个 scroll search，es 在收到该请求后会根据查询条件创建文档 id 合集的快照，并返回一个 scroll id
第二步使用 scroll id 进行 scorll 操作，获取数据集合和下一批次的 scroll id，不断迭代调用直到返回 hits.hits 数组为空时停止。

这里每次调用都可以在此指定快照时间，用于刷新快照有效时间，防止失效。