向量数据库

系统全景与谱系图谱

核心系统架构约 25 分钟kp-018

前置知识

一句话定义

向量检索的承载系统分四大谱系:专用向量库(Milvus/Qdrant/Weaviate/Chroma)、关系库扩展(pgvector 系)、搜索引擎扩展(Elasticsearch/OpenSearch/Redis/MongoDB)、嵌入式算法库(FAISS/hnswlib/Usearch)——选型的第一问不是"哪个最好",而是"我的场景属于哪个谱系"。

为什么重要

这是 33 篇知识里最具决策价值的一篇:工程师最常见的浪费,是"用专用分布式向量库解决十万级问题"或"用算法库硬扛需要过滤与高可用的生产场景"。谱系地图让你 30 秒内排除掉 3/4 的选项,把精力留给真正的比较(kp-027 决策树的骨架)。

前置知识

kp-001(向量库与算法库的分界)。

核心概念

原理与机制

谱系图谱(读法:纵向是"向量的地位",横向是"运维复杂度"):

              算法能力        数据库能力           运维重量
嵌入式库      FAISS/hnswlib   无(自己写)           零(进程内)
关系库扩展    pgvector        事务/SQL/生态完整     低(既有PG)
搜索引擎扩展  ES/OpenSearch   搜索生态/混合检索     中(既有集群)
专用单机      Qdrant/Chroma   过滤/持久化/快照      中低
专用分布式    Milvus/集群版   分片/副本/多租户      高(K8s级)
托管服务      Zilliz/Pinecone 同上+免运维           低(钱换的)

各谱系的天然优势与代价:嵌入式库速度上限最高、成本最低,但过滤、持久化、更新、高可用全部自己造——适合"索引嵌入应用进程"的场景;pgvector 白嫖 PostgreSQL 的事务、备份、权限与团队熟悉度,量级天花板在千万级到亿级(依赖硬件与调参);搜索引擎扩展赢在混合检索生态(BM25+向量+kNN 原生同引擎)与既有集群复用,代价是 JVM 资源开销与参数复杂;专用向量库赢在向量特化(filterable HNSW、量化、稀疏向量)与横向扩展,代价是新系统运维负担。

公式或模型

本节不适用:谱系总览篇,无计算模型;各系代表产品的深入剖析见 kp-019/020/021。

图示

见上方谱系图;配套能力检查表(选型时逐列打勾):

能力算法库pgvectorES 扩展专用单机专用分布式
ANN 索引多种自选HNSW/IVFHNSW/LSH?HNSW/量化全家桶+DiskANN
标量过滤自建SQL 原生生态强filterable HNSW分区+倒排
混合检索自建需外挂原生部分原生稀疏向量
写删语义自建事务准实时段式段式+一致性
水平扩展无读写分离/分区分片成熟集群版原生
团队依赖算法强会 PG 即可会 ES 即可需学新系统需 K8s

实例或案例

同一语义搜索需求的四种落地(均为真实常见的工程选择):

  1. 内部工具 5 万条 FAQ → FAISS/Flat 嵌入 Python 服务,零运维(kp-006 的适用域)。
  2. SaaS 主业务,数据已在 RDS PostgreSQL → pgvector,事务与业务表同库 join。
  3. 已有 Elasticsearch 集群的电商搜索 → 8.x dense_vector + 原生混合检索,复用运维与分析栈。
  4. 多租户 10 亿级文档、过滤复杂、QPS 高 → Milvus 分布式或 Qdrant 集群 + 托管化。

直观类比

选谱系像选交通工具:算法库是自行车(快、零成本,但只能自己骑短途);pgvector 是家用轿车(够用、顺手、全家都会开);搜索引擎扩展是改装房车(现成底盘加功能);专用分布式是重卡(运量大,需要 A2 驾照与路权);托管服务是叫专车(贵但不用自己开)。

常见误区

  1. "新项目默认上专用向量库"——多数场景 pgvector 或嵌入式库就到最优解;新系统运维成本是真实负债(kp-023 展开专篇)。
  2. "算法库 = 免费的向量库"——FAISS 进程内无持久化/过滤/高可用,把"自己补齐这些"的工作量算进去,往往比直接用向量库更贵。
  3. "谱系互斥"——生产常见组合是"pgvector 服务主业务 + FAISS 服务离线去重",按 workload 拆分而非一刀切。

自测题

  1. 四大谱系各自的"决定性优势"是什么?
  2. 答:算法库=极致轻量与速度上限;pgvector=事务生态与团队熟悉度;搜索引擎扩展=混合检索生态与既有集群;专用库=向量特化与横向扩展。

  3. 判断"必须离开算法库"的三个信号?
  4. 答:需要持久化与增量更新、需要标量过滤与多租户、需要高可用与水平扩展——任一出现即应上数据库形态。

  5. 已有 ES 集群且需求是混合检索,为什么倾向搜索引擎扩展而非新上专用库?
  6. 答:BM25+向量同引擎原生融合、复用既有运维/监控/权限体系;新上专用库的收益(向量特化性能)需对超过集成成本时才成立。

与其他知识点的关系

kp-019/020/021 是三大谱系代表产品的深度剖析;kp-023 是选型误区的专篇;kp-027 把本篇谱系图编码成可执行的决策树。

延伸阅读

Wang et al., "Milvus: A Purpose-Built Vector Data Management System"(SIGMOD 2021)——"向量库应当是数据管理系统而非算法库"论点的系统级论证。

相关知识点