【向量检索引擎】分布式 search 归并：Delegator、多级 reduce 与 GuaranteeTs

单段上的 Knowhere Query（第 8 篇）只产生 局部候选。用户一次 search 要的是 Collection 级 Top-\(k\)（或范围查询结果）。本文钉住官方查询流中的 多级归并树，以及可见性水位如何让「更强一致性」变成「更长等待」。

本文是「向量检索引擎」系列第 9 篇（共 18 篇）。→ 系列目录

版本锚定：Milvus 2.6.x Data Processing、Architecture Overview、Streaming Service、Timestamp、Consistency Level。

一、一次 search 的官方路径

Data Processing · Data query：

1. Collection 拆成多 segment；Streaming Node 持 Growing，Query Node 持 Sealed。
2. Proxy 向 相关 shard 的 Streaming Node 并发发起请求。
3. 每个 Streaming Node：搜本地 Growing；向相关 Query Node 取历史结果；聚合成 shard 结果。
4. Proxy 收集各 shard 结果，合并为最终结果返回。

Architecture 的 search 示例流补充 reduce 层次：

1. Query Node：跨其加载的多个 Sealed segment reduce；
2. Streaming Node：归并本地 Growing 与各 Query Node 结果；
3. Proxy：归并所有 Streaming Node（shard）结果。

flowchart TB
  proxy["Proxy final reduce"]
  sn0["Streaming Node shard0<br/>Delegator"]
  sn1["Streaming Node shard1<br/>Delegator"]
  qnA["Query Node A<br/>segment reduce"]
  qnB["Query Node B<br/>segment reduce"]
  proxy --> sn0
  proxy --> sn1
  sn0 --> qnA
  sn0 --> qnB
  sn1 --> qnA

这与经典 MPP「Coordinator 下发、叶子执行、根上聚合」同构；区别是叶子执行的是 ANN 段检索 + 标量约束，不是 SQL 算子树（可对读 query-engine 的 Exchange 直觉，勿混实现）。

二、Query Delegator：shard 内的拼装点

Streaming Service：Query Delegator 驻留在 Streaming Node，负责 单 shard 增量查询：

• 生成查询计划；
• 转发到相关 Query Node；
• 聚合结果；
• 广播 Delete 到其它 Query Node。

多副本时，除与 WAL 共存的 Delegator 外，还可有额外 Delegator 实例（第 5、14 篇）。对归并而言： shard 级正确性与计划在 Delegator；跨 shard 正确性在 Proxy。

三、Top-\(k\) 归并的接口直觉

设全局要求返回 \(k\) 个最近邻。若有 \(s\) 个 shard，朴素策略是：

1. 每个 shard（或每个 segment）取不少于 \(k\) 的局部候选（常取 Top-\(k\)，在过滤场景可能需要更多候选——第 11 篇）；
2. 上一层按距离/内积评分合并，再截断到 \(k\)。

数学上，若距离可比较且各分区覆盖全集的不交并，则 各分区 Top-\(k\) 的并集再取 Top-\(k\) 可得正确全局 Top-\(k\)。过滤、一致性裁剪、软删 bitset 会破坏「局部 Top-\(k\) 足够」的假设——这是混合检索篇的核心工程点，本篇先假定「候选集已按可见性过滤」。

Proxy 侧的最终 reduce 还包含官方所说的 post-process（Access Layer）：例如跨 shard 去重、格式整理。超大并发时 Proxy 成为归并热点（第 4、17 篇）。

四、GuaranteeTs：一致性如何变成等待

Consistency Level：存算分离下，执行节点可能尚未看见全部最新流式更新；Milvus 用时间戳与 GuaranteeTs 约束搜索范围。用户多通过一致性级别间接设置 GuaranteeTs（Strong / Bounded / Session / Eventually；默认 Bounded）。

Timestamp 文档用 Service_timestamp 与 Guarantee_timestamp（及可选 Graceful_time）比较：

四级的直观含义（官方 Consistency）：

第 4 篇已强调：2.6 的 Growing/Sealed 分流后，文档示意图里的「QueryNode 收流」应映射到 参与本次查询的执行路径整体水位。归并树每一层都只能合并 自己可见集合上的候选；水位不足时不是「少归并几段」，而是 整次请求等待或在放宽一致性下接受更旧视图。

五、与「单机 FAISS search」的差别清单

调参只改 ef / nprobe 却忽略一致性级别与 handoff 状态，是把分布式系统当成单索引用。

六、学术谱系、工程间隙、开放问题

6.1 谱系

6.2 工程间隙

• Strong 一致性下的尾延迟往往来自 等待水位，而非 Knowhere 变慢。
• shard 倾斜（某一 vchannel 数据远多于其它）会让 Proxy 等待最慢 shard——与 Kafka 分区倾斜同类。
• 多级 reduce 放大序列化与 RPC；候选 $k$ 过大时内存峰值在 Proxy。

6.3 开放问题

1. 过滤下最优「局部候选倍数」如何自适应（第 11 篇）？
2. 是否应在 Streaming Node 层做近似预聚合以减 Proxy 带宽？
3. Session 一致性在多客户端写入同一 Collection 时的产品语义边界？

七、小结

分布式 search 是 Delegator 拼 Growing+Sealed，Proxy 拼各 shard 的多级 reduce；一致性通过 GuaranteeTs 与执行水位的比较注入等待。下一篇进入离线数据面：Data Node：compaction 与 index build。

参考资料

1. Milvus Documentation v2.6.x, Data Processing（data query）。
2. Milvus Documentation v2.6.x, Architecture Overview（search 多级 reduce）。
3. Milvus Documentation v2.6.x, Streaming Service（Query Delegator）。
4. Milvus Documentation v2.6.x, Timestamp、Consistency Level。
5. 第 4、5、7、8 篇、系列 index。

返回 系列目录 ｜ 上一篇：对象存储布局 ｜ 下一篇：Data Node compaction