6.1 开源项目对比

6.1 开源项目对比

选型是本章的起点，本节给出主流开源项目的分类地图与一套可操作的对比方法。先立一个态度：具体产品的性能数字会随版本迭代翻盘，本节因此把重点放在分类逻辑与验证清单上——类别判断告诉你该把谁请进决赛圈，验证清单告诉你冠军怎么产生。第五章的基准方法在这里是现成的武器。

四个门派，各自的立身之本

独立分布式门派以专用向量数据库自居，代表是 Milvus、Qdrant、Weaviate：完整覆盖存储、索引、过滤、副本、多租户，Milvus 走存算分离的大集群路线、组件可独立扩缩，适合亿级与多业务线共用一个集群的组织；Qdrant 以单机性能与过滤检索见长、运维面小；Weaviate 内置模块化向量化与混合检索，开箱能力多。这一门派的共同代价是"又一座数据库要养"——备份、监控、升级、容量规划全套接管。扩展派在已有数据库里加向量能力，代表是 pgvector（PostgreSQL 扩展）、Elasticsearch 与 OpenSearch 的向量字段、Redis 的向量模块：最大优势是复用现成的运维体系、事务能力与业务数据同库，检索增强生成场景里"文档和向量在一起"的简洁性无可替代；代价是索引能力与过滤性能的天花板低于专业产品，亿级强过滤场景要实测再定。轻量嵌入式门派以 Chroma、LanceDB 为代表：进程内或单文件运行，十几行代码起步，演示、原型、小工具的天地；天花板也明确——单机容量与可用性。经典库门派是 FAISS、hnswlib 这样的算法库：没有服务层，性能与灵活性最强，适合做自研引擎的内核或离线批量任务，但持久化、并发、过滤全要自己包。

图 6-1 开源方案选型矩阵

一张对比表与一套验证清单

表格缩小范围，清单完成判决。对入围产品，逐项实测这些项：强过滤下的召回与延迟（把第五章的基准脚本套上过滤条件再跑一遍，这是独立产品宣传最少、翻车最多的项）；写入吞吐与可见性延迟（4.3 的语义在现场验证）；删除与墓碑回收（删三成数据后看性能曲线）；断电恢复时长（直接拔电演练，4.4 的纪律）；内存账（用真实规模算，含索引与副本）。每项留下数据与版本号，选型报告的可信度全在这里。

快速上手：把候选跑起来的最短路径

评估的第一步是让候选在本地跑起来，用容器拉起两个典型形态：

# 形态一：轻量服务器型，一行拉起，自带控制台
docker run -p 6333:6333 qdrant/qdrant

# 形态二：扩展派，在现有关系库里开启向量能力
# 已有 PostgreSQL 实例中创建扩展
CREATE EXTENSION vector;
CREATE TABLE docs (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(768)
);
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);
​

两段命令背后是两种哲学：前者十分钟就能把第五章的基准脚本对准它跑；后者让向量与业务表同住，一条 SQL 完成混合查询。花半天把两个形态都实测一遍，比读十篇对比文章有用。

问题：什么情况下扩展派（在现有库上加向量）是正解？

三类信号支持选扩展派。其一，数据规模在千万级以内且增速平缓，现有数据库的索引能力足够覆盖；其二，业务强依赖与主数据的同事务操作——向量与业务行必须一起更新、一起回滚，双库同步的复杂度远超向量检索本身的收益；其三，团队没有多余精力养一套新存储，而现有库的运维体系成熟。反面信号同样明确：亿级规模、强过滤下的高并发、频繁的全量重建需求，这三件事会把扩展派逼到天花板，提前规划独立向量库的演进路径。判断的本质是"向量是业务的附属数据面还是核心检索面"——附属就住host，核心就自立门户。

问题：选型测试要投入多少资源才够？

按"一周一个候选"的节奏组织就够产出可信结论。第一天搭环境灌真实规模数据（不是抽样缩微版——索引行为随规模非线性变化）；第二到四天跑验证清单五项，每项留下脚本与数据；第五天做故障演练（杀节点、断盘）；最后一天写报告。两个防坑提醒：灌数据务必含真实的增删分布，纯插入测出的性能比真实负载乐观得多；测试集群的硬件配置要记录并尽量对齐生产——CPU 代际与内存带宽的差异能轻易翻转性能结论。

表格之外的选型变量

性能与功能之外，有三个变量常被低估。许可证与商业模式：同是开源，许可证条款与核心功能的开放边界差异很大，有的产品把最先进的索引放在商业版，选型时要把自己用到的特性逐一对着许可证核一遍。社区与版本节奏：issue 的响应速度、版本发布频率、破坏性升级的历史记录，决定未来数年的升级体验，比 benchmark 名次更影响总拥有成本。退出成本：数据导出工具的完备度、备份格式的开放性，决定将来迁移的难度——把"试导出"作为选型测试的固定最后一项，导不干净的数据是隐形的高利贷。

问题：要不要等下一代产品再定？

不要等，但要把"换"的成本算进今天的决定。这个品类迭代快，两年后的领先者未必是今天的——应对之道不是观望（观望的成本是业务一直没有检索能力），而是降低切换成本：接口收口让换库只动一层适配器，数据定期导出让迁移有现成通道，验证清单让新候选一进决赛圈就能被公平度量。把这三件事做扎实的团队，选谁都不怕换；没做的团队，选谁都是终身绑定。

本节要点回顾

• 四个门派：独立分布式、扩展派、嵌入式、算法库，先分类再进决赛圈。
• 强过滤性能是选型实测的第一项，宣传最少、翻车最多。
• 验证清单五项：过滤召回、写入语义、墓笔回收、断电恢复、真实内存账。
• 扩展派的价值是数据与运维同库，代价是索引天花板，亿级强过滤要实测。
• 演进路径先轻后重，升级按触发条件走，不为想象中的规模提前买单。

开源版图看完，下一节看托管服务与框架生态：不自己养数据库的路线长什么样。