关于后端:ES-分布式搜索的运行机制

ES 分布式搜寻的运行机制

ES 有两种 search_type 即搜寻类型：

• query_then_fetch（默认）
• dfs_query_then_fetch

query_then_fetch

1. 用户发动搜寻，申请到集群中的某个节点。
2. query 会被发送到所有相干的 shard 分片上。
3. 每个 shard 分片独立执行 query 搜寻文档并进行排序分页等，打分时应用的是分片自身的 Local Term/Document 频率。
4. 分片的 query 后果（只有元数据，例如 _id 和 _score）返回给申请节点。
5. 申请节点对所有分片的 query 后果进行汇总，而后依据打分排序和分页，最初抉择出搜寻后果文档（也只有元数据）。
6. 依据元数据去对应的 shard 分片拉取存储在磁盘上的文档的具体数据。
7. 失去具体的文档数据，组成搜寻后果，将后果返回给用户。

毛病：因为每个分片独立应用本身的而不是全局的 Term/Document 频率进行相关度打分，当数据分布不平均时可能会造成打分偏差，从而影响最终搜寻后果的相关性。

dfs_query_then_fetch

dfs_query_then_fetch 与 query_then_fetch 的运行机制十分相似，然而有两点不同。

1. 用户发动搜寻，申请到集群中的某个节点。
2. 预查问每个分片，失去全局的 Global Term/Document 频率。
3. query 会被发送到所有相干的 shard 分片上。
4. 每个 shard 分片独立执行 query 搜寻文档并进行排序分页等，打分时应用的是分片自身的 Global Term/Document 频率。
5. 分片的 query 后果（只有元数据，例如 _id 和 _score）返回给申请节点。
6. 申请节点对所有分片的 query 后果进行汇总，而后依据打分排序和分页，最初抉择出搜寻后果文档（也只有元数据）。
7. 依据元数据去对应的 shard 分片拉取存储在磁盘上的文档的具体数据。
8. 失去具体的文档数据，组成搜寻后果，将后果返回给用户。

毛病：太消耗资源，个别还是不倡议应用。

教训

• 尽管 ES 有两种搜寻类型，但个别还是都用默认的 query_then_fetch。
• 当数据量没有足够大的状况下（比方搜寻类型数据 20GB，日志类型数据 20-50GB），设置一个 shard 主分片是比拟举荐的，只设置一个主分片，你会发现搜寻时省掉了好多事件。
• 不须要文档数据时，应用 _source: false 能够防止申请节点到非本机分片的网络耗时以及读取磁盘文件的耗时。
• 应用 from + size 分页时，假如你只须要前 10k 条数据里的最初十条，那么每个分片也会取 10k 条数据，如果你的索引有 5 个主分片，那么汇总时就有 5 * 10k = 50k 条数据，这 50k 条数据是在内存里进行排序和最初的分页的，所以深度分页也是比拟吃资源的。