共计 1172 个字符，预计需要花费 3 分钟才能阅读完成。
search 的运行机制
node3 在接管到用户申请时，先进行 query 阶段，此时为 coordinating Node 角色
- node3 在六个主副分片中随机抉择三个分片，发送 search
- 被选中的分片会别离执行查问并拍寻，返回 from+size 的文档 id 和排序值
- node3 整合三个分片返回的 from+size 文档 id，依据排序值排序后选取 from 到 from+size 的文档 id
相关性算分
- 相关性算分在 shard 与 shard 之间是独立的，也就意味着同一个 term 的 idf 等值在不同的 shard 上是不同的，文档的相关性算分和它所处的 shard 相干。
- 在文档数量不多，会导致相关性算分重大不准的状况产生。
解决思路
- 设置分片数为 1，从根本上排除问题，在文档不多时能够应用该办法，例如 百万到千万级别的文档数量
应用 dfs query-then-fetch 查问形式
- dfs 在拿到所有文档后再从新进行相关性算分，须要更多 cpu 和内存资源，性能较差，个别不倡议应用。
sort
- es 会默认采纳相关性算分进行排序，用户可指定 sort 字段，来设置排序规定
- 依照字符串排序比拟非凡，因为 es 有 text 和 keyword 两种类型，针对 text 类型
- 排序的过程本质是对字段原始内容排序的过程，这个过程倒排索引无奈发挥作用，须要用到正排索引，也就是通过文档 id 和字段能够疾速失去字段的原始内容。
es 对此提供两种实现形式
- fielddata 默认禁用
- doc values 默认启用 除了 text 类型
fielddata 通过 api 开启
- 此时字符串是依照分词后的 term 排序，往往后果很难复合预期
- 个别是对分词做聚合剖析时开启
- doc values 默认启用，在创立索引时关系，若须要再次开启，则须要 reindex 操作
- 可通过该字段获取 fielddata 或者 doc values 中存储的内容
from size 分页
from 起始地位 size 获取总数
深度分页 在数据分片存储的状况下如何获取前 1000 个文档
- 获取 990-1000 文档时，会在每个分片上都获取 1000 文档，而后再由 coordinatingnode 聚合素有的分片后果再排序选取前 1000 个
- 页数越深，解决文档越多，占用内存越多，耗时越唱，尽量避免深度分页，es 通过 index.max_result_window 限定最多到 10000 条数据
scroll
遍历文档汇合的 api 以快照的形式来防止深度分页问题
- 不能用来做实时搜寻，数据不是实时的
- 尽量不应用简单的 sort 条件，应用_doc 最高效
- 应用时稍显麻烦
search_after
防止深度分页的性能问题 提供实时的下一页文档获取性能
- 毛病时不能应用 from 参数 即不能指定页数
- 只能下一页 不能上一页
应用简略
- 失常搜寻 但要指定 sort 值 并且保障值惟一
- 应用上一步最初一个文档的 sort 值进行查问
如何防止深度分页问题
- 通过惟一排序定位将每次要解决的文档数管制在 size 内
正文完
