关于java:elastic-stack-那些事6

search 的运行机制

node3 在接管到用户申请时，先进行 query 阶段，此时为 coordinating Node 角色

1. node3 在六个主副分片中随机抉择三个分片，发送 search
2. 被选中的分片会别离执行查问并拍寻，返回 from+size 的文档 id 和排序值
3. node3 整合三个分片返回的 from+size 文档 id，依据排序值排序后选取 from 到 from+size 的文档 id

相关性算分

1. 相关性算分在 shard 与 shard 之间是独立的，也就意味着同一个 term 的 idf 等值在不同的 shard 上是不同的，文档的相关性算分和它所处的 shard 相干。
2. 在文档数量不多，会导致相关性算分重大不准的状况产生。

解决思路

1. 设置分片数为 1，从根本上排除问题，在文档不多时能够应用该办法，例如 百万到千万级别的文档数量

2. 应用 dfs query-then-fetch 查问形式

   1. dfs 在拿到所有文档后再从新进行相关性算分，须要更多 cpu 和内存资源，性能较差，个别不倡议应用。

sort

1. es 会默认采纳相关性算分进行排序，用户可指定 sort 字段，来设置排序规定
2. 依照字符串排序比拟非凡，因为 es 有 text 和 keyword 两种类型，针对 text 类型
3. 排序的过程本质是对字段原始内容排序的过程，这个过程倒排索引无奈发挥作用，须要用到正排索引，也就是通过文档 id 和字段能够疾速失去字段的原始内容。

4. es 对此提供两种实现形式

   1. fielddata 默认禁用
   2. doc values 默认启用 除了 text 类型

5. fielddata 通过 api 开启

   1. 此时字符串是依照分词后的 term 排序，往往后果很难复合预期
   2. 个别是对分词做聚合剖析时开启
6. doc values 默认启用，在创立索引时关系，若须要再次开启，则须要 reindex 操作
7. 可通过该字段获取 fielddata 或者 doc values 中存储的内容

from size 分页

from 起始地位 size 获取总数

深度分页 在数据分片存储的状况下如何获取前 1000 个文档

1. 获取 990-1000 文档时，会在每个分片上都获取 1000 文档，而后再由 coordinatingnode 聚合素有的分片后果再排序选取前 1000 个
2. 页数越深，解决文档越多，占用内存越多，耗时越唱，尽量避免深度分页，es 通过 index.max_result_window 限定最多到 10000 条数据

scroll

遍历文档汇合的 api 以快照的形式来防止深度分页问题

1. 不能用来做实时搜寻，数据不是实时的
2. 尽量不应用简单的 sort 条件，应用_doc 最高效
3. 应用时稍显麻烦

search_after

防止深度分页的性能问题 提供实时的下一页文档获取性能

1. 毛病时不能应用 from 参数 即不能指定页数
2. 只能下一页 不能上一页

3. 应用简略

   1. 失常搜寻 但要指定 sort 值 并且保障值惟一
   2. 应用上一步最初一个文档的 sort 值进行查问

4. 如何防止深度分页问题

   1. 通过惟一排序定位将每次要解决的文档数管制在 size 内