土法炼钢兴趣小组的算法知识备份

【向量检索引擎】Qdrant 对照:单库路径、payload 过滤与分片副本

文章导航

分类入口
databasestorage
标签入口
#qdrant#milvus#payload-filter#sharding#raft#hnsw#vector-engine

目录

Milvus 2.6.x 主线强调存算分离与 Streaming/Query/Data 三分(第 1–14 篇)。Qdrant 走另一条常见生产路径:Rust 实现的向量库,单节点即可完整服务,分布式用 分片 + 副本 扩展。本文按官方 Distributed deploymentFiltering 做对照,不写成 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 拆 shardreplication_factor 控制副本

核心差异不是「谁的 HNSW 更好」,而是 状态放哪、组件拆多细、运维面多大


二、单节点甜区

Qdrant 官方 Distributed deployment 明确:若最看重成本,可跑 单节点——同时写明不适合生产高可用(重启即停服、无副本则难自愈)。

工程含义:

Milvus 也有单机/精简部署形态,但本系列内核叙事默认云原生四分;选型时比较的是你真正要运维的拓扑,不是营销页上的「也能 Docker 一键起」。


三、分布式:分片、副本与共识分工

Distributed deployment(A 级要点):

官方 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 篇给出决策树;本篇只钉对照坐标。


六、开放问题

  1. Qdrant 自定义 sharding key 与 Milvus partition 在多租户下的运维成本比较。
  2. 两边 HNSW 参数默认值不同导致的「同数据不同召回」评测规范。
  3. 混合云(厂商托管)下,对照应比较 SLO 与锁定,而非开源内核 alone。

七、小结

Qdrant 用 单进程完整路径 + 可选分片副本集群 换运维简单;Milvus 用 存算分离多 Worker 换弹性与离线建索隔离。过滤都是「标量条件进检索」,载体分别是 payload index 与 bitset/表达式。下一篇:Lance / LanceDB 对照


参考资料

  1. Qdrant Documentation, Distributed deployment(shard、replication_factor、节点数权衡)。
  2. Qdrant Documentation, Filtering(payload、clauses、payload index)。
  3. Qdrant Documentation, Overview(部署模型与扩展叙述)。
  4. 本系列第 1、3、5、11、14 篇;系列 index

返回 系列目录 | 上一篇:副本与故障恢复 | 下一篇:Lance 对照

同主题继续阅读

把当前热点继续串成多页阅读,而不是停在单篇消费。


By .