Elasticsearch搜索原理及详细过程讲解

Elasticsearch 的搜索过程是一个高效、分布式的流程，设计用于在大量数据中快速定位相关信息。以下是其详细步骤：

核心流程：分散/聚集模型 (Scatter/Gather)

Elasticsearch 的搜索本质上是 分散 请求到相关分片，然后 聚集/合并 结果的过程。

1. 客户端发起请求 (Client Request Initiation)

• 用户或应用程序向 任意一个 Elasticsearch 节点（通常通过 REST API）发送搜索请求 (GET /<index>/_search)。
• 请求包含查询 DSL（如 match, term, bool 查询）、过滤条件、排序、分页（from/size）、高亮、聚合等参数。
• 收到请求的节点自动成为本次搜索请求的 协调节点 (Coordinating Node)。

2. 查询解析与路由 (Query Parsing & Routing)

• 协调节点 解析查询 DSL，确定需要搜索哪些 索引 (Indices)。
• 对于每个目标索引，协调节点根据索引的 分片 (Shards) 配置（主分片数量）和 路由策略（通常基于文档 ID 的哈希）：
  • 计算查询应该发送到哪些 分片副本 (Shard Replicas)。
  • ES 默认会将搜索请求 轮询 (Round-Robin) 发送到索引的所有分片（包括主分片和副本分片）的一个副本。这样做是为了充分利用所有节点的资源，实现负载均衡。
  • 如果查询指定了路由参数 (routing)，协调节点会根据路由值计算出目标分片 ID，并只将请求发送到该特定分片（及其副本）。

3. 查询阶段 - 分散到分片 (Query Phase - Scatter)

• 协调节点 将解析和处理后的搜索请求 并行地 发送到在步骤 2 中确定的所有 相关分片副本（目标分片的主分片或副本分片）。
• 每个目标分片副本 在其本地独立执行查询：
  • 加载倒排索引： 查找查询词项在倒排索引中对应的文档 ID (_id) 列表。
  • 执行查询逻辑： 根据查询类型（布尔组合、短语匹配、范围查询等）处理这些文档 ID 列表，过滤掉不匹配的文档。例如：
    • Term Query: 直接查找对应 term 的倒排列表。
    • Match Query: 分词后对每个词项查找倒排列表，再按逻辑（如 OR）合并。
    • Bool Query: 组合多个子查询的 MUST/MUST_NOT/SHOULD/FILTER 逻辑。
    • Range Query: 查找数值或日期范围字段的倒排索引或 Doc Values。
  • 评分 (Scoring - 如果适用)：
    • 对于需要相关性排序 ("sort": [{"_score": "desc"}]) 或 track_scores: true 的查询，每个分片使用选定的相似度算法（如 TF/IDF, BM25）计算匹配文档的 本地相关性分数 (_score)。评分基于该分片本地的词频、逆文档频率等统计信息。
    • FILTER 上下文 中的查询条件（如 filter 子句、bool 的 filter 或 must_not）不参与评分，只用于二元过滤，效率通常更高。
  • 构建优先级队列：
    • 每个分片根据请求的 size 和 from（或 search_after）参数以及排序规则（默认按 _score 降序），在本地维护一个优先级队列 (Priority Queue)。
    • 队列的大小是 size + from (对于 Top-K 结果合并足够)。
    • 该队列保存了当前分片本地得分最高（或按指定排序规则最靠前）的 size + from 个文档的元数据：文档 ID (_id)、分片 ID、排序字段值（主要是 _score）。注意：此时并不获取文档的实际源数据 (_source) 或存储字段。

4. 查询阶段 - 聚集结果 (Query Phase - Gather)

• 所有目标分片副本将其本地执行的查询结果（即包含文档 ID、分片 ID、排序值的优先级队列）并行地 发送回 协调节点。
• 协调节点 接收来自所有分片的结果。
• 协调节点合并与排序：
  • 协调节点将来自各个分片的优先级队列 合并 成一个全局的优先级队列。
  • 这个全局队列的大小是用户请求的 size + from。
  • 合并时，根据请求指定的排序规则（默认 _score 降序）决定文档在全局结果中的最终顺序。
  • 关键点： 协调节点此时只持有全局 Top (size + from) 结果的 文档 ID (_id)、分片位置、_score 等排序元数据，仍然没有文档内容 (_source)。

5. 取回阶段 (Fetch Phase)

• 一旦协调节点确定了全局排序后的最终文档列表（from 到 from + size 之间的文档），它需要获取这些文档的完整内容 (_source) 和/或任何显式请求的存储字段(stored_fields)。
• 协调节点 向 持有这些文档实际数据的分片 发送 多文档获取请求 (Multi-Get Request / mget)。
  • 请求包含需要获取的文档的 _id 和它们所在的具体分片 ID。
• 相关分片 接收到 mget 请求后：
  • 根据 _id 在其本地存储中查找对应的文档。
  • 加载 _source： 从存储（通常是文件系统缓存中的 Lucene 段文件）中读取文档的原始 JSON 源数据 (_source)。
  • 应用高亮 (Highlighting)： 如果需要，对 _source 中指定字段的内容执行高亮处理（查找匹配词并添加高亮标签）。
  • 应用字段过滤： 如果请求指定了 _source 过滤（如 "_source": ["title", "date"]），则只返回请求的字段。
  • 将处理好的文档数据（_id, _source, 高亮结果，存储字段等）返回给协调节点。

6. 最终响应组装与返回 (Response Assembly & Return)

• 协调节点 收集来自各个分片的 mget 响应。
• 它组装最终的搜索结果响应 (Search Response)：
  • hits 数组：包含排好序的实际文档数据 (_source)，高亮信息等。数组长度由 size 决定，跳过前 from 个结果。
  • hits.total：匹配文档的总数 (这是一个下限值，如需精确值需设置 track_total_hits: true，代价较高)。
  • took：整个搜索请求消耗的总时间（毫秒）。
  • _shards：报告参与搜索的分片总数、成功数、失败数。
  • aggregations (如果请求了聚合)：包含聚合结果。
  • 其他信息：如是否超时 (timed_out)、滚动 ID (_scroll_id) 等。
• 协调节点 将组装好的最终 JSON 响应返回给原始客户端。

关键概念与注意事项

1. 分布式本质：

   • 查询在每个分片本地并行执行，极大提高速度。
   • 协调节点负责路由、分发、合并和最终组装。

2. 深度分页 (Deep Pagination) 问题：

   • 当 from + size 的值非常大时（如 from: 10000, size: 10），每个分片都需要构建一个大小为 10010 的本地优先级队列，协调节点需要合并 number_of_shards * 10010 个结果来找到全局的 Top 10010，然后只返回最后 10 个。这对 CPU、内存和网络带宽消耗巨大，性能极差。
   • 解决方案： 使用 search_after 参数（基于上一页最后一个结果的排序值）或滚动 API (scroll)（用于深度遍历或导出，非实时）替代传统的 from/size。

3. 相关性评分 (_score)：

   • 评分在每个分片本地计算，基于该分片的本地统计信息（如 IDF）。这在大集群中通常是足够准确的近似值。
   • 如果索引非常小或要求极端精确的全局评分（代价很高），可设置 search_type: dfs_query_then_fetch。它会在查询阶段增加一个额外的步骤，先收集所有分片的全局词频统计信息，再分发下去重新评分。通常不推荐使用，除非绝对必要。

4. 聚合 (Aggregations)：

   • 聚合计算也是在查询阶段在每个分片上并行执行的（构建桶、计算指标）。
   • 每个分片返回其本地聚合结果（部分桶和指标）。
   • 协调节点负责将来自所有分片的聚合结果合并成全局聚合结果（例如，合并桶、累加总和、计算全局平均值等）。这通常非常高效。
   • 某些聚合（如 terms）默认返回的是每个分片的 Top 桶合并后的结果，可能遗漏低频项（可通过增大 shard_size 缓解）。cardinality 和 percentiles 等聚合使用近似算法。

5. 过滤上下文 (Filter Context) vs. 查询上下文 (Query Context)：

   • 查询上下文： 影响评分 (_score)，用于全文搜索和相关性排序。must/should 通常在此上下文。
   • 过滤上下文： 只关心文档是否匹配（是/否），不评分。结果会被缓存，性能更高。filter/must_not/constant_score 通常在此上下文。将不关心评分的条件放入 filter 可以显著提升性能。

6. 缓存：

   • 分片级请求缓存： 缓存整个查询请求的结果（通常是 size=0 的聚合请求或频繁重复的查询）。默认开启，但仅缓存特定查询（如 bool 的 filter 部分）。
   • 分片级查询缓存 (Query Cache)： Lucene 级别，缓存查询结果的文档 ID 位集 (bitset)。对过滤 (filter 上下文) 性能提升明显，但对文本评分查询效果有限。默认开启但大小有限。
   • 文件系统缓存： OS 会将频繁访问的 Lucene 段文件缓存在内存中，极大加速索引读取。确保有足够内存给文件系统缓存是 ES 性能的关键。

7. 副本的作用：

   • 副本不仅提供高可用性，也能分担读负载（搜索请求）。协调节点会将请求发送到分片副本（主或副），实现负载均衡。

总结流程图示：

[客户端]
   |
   | (1. 发送搜索请求)
   V
[协调节点]
   |
   | (2. 解析查询, 确定目标分片)
   |--------------------------------------------------
   |                                                  |
   V (3a. 发送查询请求)                              V (3a. 发送查询请求)
[分片副本 A]                                     [分片副本 B]
   | (执行本地查询, 构建优先级队列)                  | (执行本地查询, 构建优先级队列)
   | (4a. 返回文档ID/分片/分数队列)                 | (4a. 返回文档ID/分片/分数队列)
   |                                                  |
   |<-------------------------------------------------|
   |
   V
[协调节点]
   | (4b. 合并所有分片的队列, 确定全局Top-K)
   |
   | (5a. 发送mget请求获取具体文档)
   |--------------------------------------------------
   |                                                  |
   V (5b. 返回文档_source/高亮)                     V (5b. 返回文档_source/高亮)
[分片副本 A] (持有Doc X)                         [分片副本 N] (持有Doc Y)
   |                                                  |
   |<-------------------------------------------------|
   |
   V (6. 组装最终响应)
[协调节点]
   |
   | (返回搜索结果给客户端)
   V
[客户端]

理解这个分散/聚集流程对于诊断 Elasticsearch 搜索性能问题、优化查询 DSL 和配置集群至关重要。

总结

到此这篇关于Elasticsearch搜索原理及详细过程的文章就介绍到这了,更多相关Elasticsearch搜索原理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！