关于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内