Milvus 2.6.x 主线强调存算分离与 Streaming/Query/Data 三分(第 1–14 篇)。Qdrant 走另一条常见生产路径:Rust 实现的向量库,单节点即可完整服务,分布式用 分片 + 副本 扩展。本文按官方 Distributed deployment、Filtering 做对照,不写成 Qdrant 教程。
本文是「向量检索引擎」系列第 15 篇(共 18 篇)。→ 系列目录
版本锚定:Qdrant 官方文档(Distributed deployment、Filtering);与 Milvus 对照时机制以本系列已钉的 2.6.x 为准。
一、产品形态对照
| 维度 | Milvus 2.6.x(本系列) | Qdrant(官方文档) |
|---|---|---|
| 典型部署 | Proxy + Coordinator + 多类 Worker + 对象存储 + WAL | 单二进制可跑全功能;集群为对等 peer |
| 写日志 | Woodpecker / Kafka / Pulsar(第 5 篇) | 分片本地 WAL;分布式下数据复制与元数据共识分离(见下) |
| 历史数据 | Sealed 在对象存储,Query Node 加载 | 分片/segment 本地(及副本)持有 |
| 过滤 | 表达式 → bitset → Knowhere(第 11 篇) | payload 条件 + 建议建 payload index |
| 水平扩展 | Channel/shard + Worker 扩缩 | Collection 拆
shard,replication_factor
控制副本 |
核心差异不是「谁的 HNSW 更好」,而是 状态放哪、组件拆多细、运维面多大。
二、单节点甜区
Qdrant 官方 Distributed deployment 明确:若最看重成本,可跑 单节点——同时写明不适合生产高可用(重启即停服、无副本则难自愈)。
工程含义:
- 中小规模 RAG、原型、边车式检索:单进程 Qdrant 运维面远小于「MinIO + etcd + 多 Worker」的 Milvus 集群。
- 垂直扩展有上限;官方 overview 亦强调最终要靠 sharding / replication / segment 配置做水平与吞吐优化。
Milvus 也有单机/精简部署形态,但本系列内核叙事默认云原生四分;选型时比较的是你真正要运维的拓扑,不是营销页上的「也能 Docker 一键起」。
三、分布式:分片、副本与共识分工
Distributed deployment(A 级要点):
- 自 v0.8.0 支持分布式;多 Qdrant 服务互相同步以扩展容量与稳定性。
- Collection 由一个或多个 shard 组成;每个 shard 可独立完成集合提供的操作。
replication_factor:创建集合时控制每 shard 副本数;默认 1(无额外副本);生产强烈建议 ≥2。- 生产推荐叙述:三节点及以上 + 副本,可在单节点故障时继续服务并具备更强恢复能力;两节点复制是成本与韧性折中。
官方 overview / 分布式叙述还区分:元数据类操作与集群协调依赖共识(社区与架构说明中为 Raft 管元数据);点更新走副本集上的复制路径以换吞吐。本系列对照结论取:Qdrant 集群是对称 peer + 分片副本模型,不是 Milvus 式「无状态 Worker + 共享对象存储」模型。
flowchart LR
subgraph milvus ["Milvus style"]
p["Proxy"]
c["Coordinator"]
w["Workers"]
o["Object store"]
p --> c
p --> w
w --> o
end
subgraph qdrant ["Qdrant style"]
n1["Peer shard replica"]
n2["Peer shard replica"]
n3["Peer shard replica"]
n1 --- n2
n2 --- n3
end
与 Milvus Channel / vchannel(第 3 篇)对照:两者都把集合切成可并行单元,但 Qdrant shard 是 带完整点存储的对等分片;Milvus channel 绑定 Streaming Node,历史段另由 Query Node 从对象存储加载。
四、Payload 过滤
Filtering:搜索/检索时可对
payload 与点 id
设条件;业务属性(库存、地域、价格带)往往无法全部进入
embedding。
官方强调:要性能,应对过滤字段建 payload
index,且 最好在摄入数据前
建好。条件可用 must / should /
must_not 等子句嵌套,表达任意布尔组合。
对照 Milvus:
| Milvus | Qdrant | |
|---|---|---|
| 标量载体 | 字段 + 布尔表达式 | JSON-like payload |
| 加速结构 | 标量索引 + bitset 进 Knowhere | payload index |
| 选择度陷阱 | 同第 11 篇 / frontier/09 | 同样存在;索引只降过滤成本 |
不要假设「Qdrant 过滤一定比 Milvus 快」——取决于索引是否建、选择度、以及是否在图遍历中有效剪枝。
五、何时选 Qdrant 而不是上 Milvus 集群
| 更偏向 Qdrant | 更偏向 Milvus 集群 |
|---|---|
| 团队要少组件、快上线 | 已有对象存储/K8s 平台,要存算分离弹性 |
| 数据中小、可垂直扩展一阵 | 十亿级、索引构建要独立扩 Data/Index 类负载 |
| payload 过滤模型贴业务 JSON | 要强绑定多一致性级别产品语义(第 12 篇) |
| 分片副本模型可接受 | 需要 Woodpecker/零盘 WAL 等云原生写路径 |
第 18 篇给出决策树;本篇只钉对照坐标。
六、开放问题
- Qdrant 自定义 sharding key 与 Milvus partition 在多租户下的运维成本比较。
- 两边 HNSW 参数默认值不同导致的「同数据不同召回」评测规范。
- 混合云(厂商托管)下,对照应比较 SLO 与锁定,而非开源内核 alone。
七、小结
Qdrant 用 单进程完整路径 + 可选分片副本集群 换运维简单;Milvus 用 存算分离多 Worker 换弹性与离线建索隔离。过滤都是「标量条件进检索」,载体分别是 payload index 与 bitset/表达式。下一篇:Lance / LanceDB 对照。
参考资料
- Qdrant Documentation, Distributed
deployment(shard、
replication_factor、节点数权衡)。 - Qdrant Documentation, Filtering(payload、clauses、payload index)。
- Qdrant Documentation, Overview(部署模型与扩展叙述)。
- 本系列第 1、3、5、11、14 篇;系列 index。
返回 系列目录 | 上一篇:副本与故障恢复 | 下一篇:Lance 对照
同主题继续阅读
把当前热点继续串成多页阅读,而不是停在单篇消费。
【向量检索引擎】ANN 算法工程接口:从 HNSW/IVF 到 Knowhere 契约
把 HNSW、IVF、DiskANN、Flat 收成引擎侧的索引类型与参数面;说明 Train/Build/Search 生命周期如何贴着 Segment,并与 db-frontier/08 的算法细节、第 8 篇 Knowhere 实现分层分工。
【向量检索引擎】Knowhere:向量索引执行引擎与插件契约
按官方 Knowhere 文档说明其在 Milvus 中的位置、相对 Faiss 的扩展(bitset、SIMD 选择、二进制度量)、VecIndex 类层次与 IDMAP/IVF/HNSW 等类型,并与 db-frontier/08 的算法细节分工。
【向量检索引擎】选型与阅读地图:决策树、RAG 回链与开放问题
用决策树收束 Milvus、Qdrant、Lance/pgvector 的适用边界;回链 llm-infra RAG 与 db-frontier ANN;列出 GPU 索引、多向量、稀疏+稠密等开放问题,完成本系列阅读地图。
【向量检索引擎】Milvus · Segcore · Knowhere · Qdrant · Lance
补齐 ANN 算法与 RAG 应用之间的生产级向量引擎层:以 Milvus 2.6.x 为主线拆解 Segment、WAL、Segcore、Knowhere、混合过滤与一致性,并用 Qdrant、LanceDB 对照选型。