★ FEATURED ARTICLE 1. 选型之前先要回答的问题你到底在选什么被应该用哪个向量数据库这个问题反复拷问过的团队应该不在少数。我身边好几个项目组包括我自己带过的RAG应用和语义检索系统都曾在 Milvus、Qdrant、Weaviate、Pinecone、pgvector 之间来回摇摆最后发现卡住我们的往往不是性能而是没想清楚自己到底要解决什么问题。这篇文章就做一个选型视角的横向对比不鼓吹某一款产品而是把主流向量数据库的底层架构、关键能力、成本结构、典型坑点摆在一起讲清楚每个取舍背后的原因。这篇文章适合三类人正在做 RAG 知识库问答的开发者、要搭多模态检索或推荐召回平台的后端团队以及只想用最低成本快速验证一个语义搜索Demo的独立开发者。读完之后你至少能回答两个问题我的场景在哪个数据量级、什么样的查询模式哪个库的架构边界最匹配我的团队运维能力这两个问题想清楚了选型表基本也就出来了。1.1 先对号入座你是哪一类用户不同身份的用户对好用的向量数据库定义完全不同。我把这些年接触过的需求归成三类你可以先看看自己在哪一类。第一类是RAG 应用开发者。他们的典型诉求是文档切块、向量化、存入集合、按相似度召回偶尔还要按文档ID或来源做过滤。这类人最看重的是召回质量和上手速度数据量通常在千万级以下不太关心分布式集群反而特别在意 SDK 是否顺手、能不能和 LangChain 这类框架无缝衔接。第二类是检索与推荐平台团队。他们的数据量动辄上亿查询 QPS 有硬指标还需要多租户隔离、复杂条件过滤、以及向量检索和关键词检索的混合。这类人最看重的是吞吐、横向扩展能力和运维可控性愿意为此付出更多架构成本。第三类是数据科学家 / 独立开发者 / 内部工具作者。他们需要的是能跑就行、改起来快的东西数据量小到中等不想为部署集群操任何心。这三类人如果互相换产品通常会得出完全相反的结论。所以后面所有对比都不是谁更好而是谁更适合哪一类。1.2 别拿选 SQL 数据库的思路来选向量库这是我在很多团队里观察到的最典型误区大家习惯用功能清单性能跑分去选数据库但向量数据库的选型逻辑和关系型数据库差别巨大。第一个差别是没有绝对准确这回事。关系库里查一行数据结果要么对要么错向量检索用的是近似最近邻ANN召回结果是一个近似集合召回率永远到不了 100%。你需要在多准和多快之间拉扯端到端的查询链路里索引参数、量化方式、过滤顺序都会影响准确度。第二个差别是没有统一 API 标准。各家 SDK 风格完全不同迁移成本远高于从 MySQL 切到 PostgreSQL。你在一个库里写的查询逻辑换到另一个库基本要重写。第三个差别是数据规模与硬件的关系完全不同。关系库的性能瓶颈通常是磁盘和 SQL 优化向量库的性能瓶颈则往往卡在内存和索引结构上。同样的 1000 万条 768 维 float 向量裸数据就要吃掉 768×4×10000000 ≈ 307亿字节也就是约 28GB 内存这还不算索引开销。数据规模一旦翻倍可能不是加一台机器能解决的而是整个架构模式都要变。所以做横向对比之前先放下哪家跑分最高的执念把上面的三个认知差异装进脑子里。下面的逐个摸底才能看懂每一家设计取舍背后的动机。2. 当前主流的九个选手底层设计决定了它们各自的能力边界现在市面上能叫得出名字的向量数据库大概有二十多个但真正值得放进选型表里的我筛出了九个。它们可以分成三个阵营原生向量数据库、存量数据库扩展的向量能力、轻量嵌入式方案与算法库。每个阵营的架构哲学不同能力边界也完全不同。产品部署形态核心索引最突出的优势最明显的短板Milvus嵌入式 / 单机 / 分布式集群 / 云托管HNSW、IVF、SCANN、DISKANN、GPU大规模场景功能最全、扩展性强自建组件多、运维门槛高Qdrant单容器 / 集群 / 云托管HNSW 自定义过滤优化过滤性能强、部署极简单、省内存集群能力相对新、生态不如 MilvusWeaviate单机 / 集群 / 云托管HNSW 模块化向量化内置向量化模块、GraphQL、混合检索大规模场景性能调优空间偏弱Pinecone纯云托管 / Serverless内部闭源优化零运维、接入快无自建选项、数据锁定风险Chroma嵌入式HNSW SQLite 存储最易上手、Python 友好大流量/大规模不可用pgvectorPostgreSQL 扩展HNSW、IVFFlat复用现有 Postgres、支持事务和 SQL超大规模与超高性能受限Elasticsearch分布式集群HNSWdense_vector生态成熟、ES 与向量混合检索资源开销大、运维复杂Redis 向量检索内存缓存HNSWRediSearch读取极快、复用 Redis全内存、成本随规模飙升FAISS算法库非数据库Flat、IVF、HNSW、PQ索引算法标杆、支持 GPU没有服务、没有数据管理这张表只是一个第一印象接下来逐个讲清楚每家的架构逻辑你才知道表格背后那些短板的真实分量。2.1 原生向量数据库阵营为向量而生但各有各的脾气Milvus是我见过架构最重也最完整的开源向量数据库。它的设计理念是存算分离用外部对象存储放数据、etcd 管元数据、消息队列处理写入日志所以天然具备分布式基因。索引类型非常全从 HNSW、IVF 系列到 SCANN、DISKANN 都有2.4 版本之后还加入了 BM25 全文检索和分组搜索。它的优势是一个系统解决所有向量检索问题尤其适合亿级以上、多租户、混合检索平台。短板也很明显自建集群的组件多到你数不清单机部署虽然用 Docker Compose 能拉起来但要做生产高可用团队没有一定运维功底会很难受。Qdrant是 Rust 写的最大的特征是用起来省心。一个二进制文件跑起来就是一个完整服务Docker 一条命令能拉起来性能上它针对带过滤的向量检索做了大量优化这是它在 RAG 领域口碑很好的核心原因——RAG 查询几乎总是带着租户过滤或文档类型过滤。它支持标量量化和二值量化可以直接把内存占用砍掉一半以上。分布式集群能力在持续完善但对大部分团队来说单机加大内存已经能满足绝大多数生产需求。简单说它是把 80% 场景做好的务实派。Weaviate是 Go 写的走的是开箱即用的语义搜索引擎路线。它最大的差异化是模块化的向量化能力你自己可以不调 embedding API直接在库里配置 OpenAI 模型或本地 transformer 模型数据进库时自动向量化查询时用 GraphQL 一把梭。混合检索BM25 关键词 向量是原生支持的多租户和复制也有。它的问题是性能调优空间相对保守数据量大之后不如 Milvus 和 Qdrant 能打而且内置向量化模块非常吃资源。适合产品需要快速上线、团队不想单独维护 embedding 管线的语义搜索项目。Pinecone走的是完全相反的路线闭源、纯托管、不提供自建选项。它的价值在于让你完全不需要管索引、分片、扩容这些破事API 简单到不像一个数据库。后来推出的 Serverless 形态更是把成本粒度削到了按请求计费。对于团队里没人愿意运维基建的小团队它是救星但对于数据规模大、对成本和供应商锁定敏感的公司长期来看是个隐患。2.2 存量数据库阵营不想引入新组件时的务实之选pgvector可能是过去两年 RAG 项目里采用率增长最快的一个方案原因很简单很多团队本来就跑着 PostgreSQL加一个扩展就能获得向量存储和相似度检索能力还不用引入任何新组件。它支持 HNSW 和 IVFFlat 两种索引也支持精确检索用直接算距离最关键的是和 SQL、事务、JOIN 天然在一起标量过滤可以借助普通索引完成逻辑非常统一。它的天花板在于PostgreSQL 本身的单机为主架构、HNSW 索引构建与并发写入的竞争使得它在亿级数据和极高 QPS 场景下会力不从心。作为够用且省事的方案它非常适合中小型团队。Elasticsearch从 7.x 开始支持 dense_vector到 8.x 已经把 HNSW 近邻检索做得颇具规模配合它本来就有的 BM25 全文检索可以说是混合检索能力最成熟的存量系统。如果你的搜索基础设施本来就是 ES往向量方向扩展的成本很低。缺点也非常明显ES 集群本身吃内存和磁盘非常凶堆上向量数据之后资源账单会很难看查询调优的复杂度也比专用向量库高。适合那种已经有 ES 专家在维护集群的团队。Redis的向量检索模块RediSearch提供了一个很有意思的定位因为全内存查询延迟极低适合做召回缓存、热榜推荐这类对延迟极度敏感的小数据量场景。但它本质是个缓存系统大规模向量全放内存的成本高到离谱也没有复杂查询计划和持久化体系。我的建议是可以把它放进化石方案名单但别把它当主力库。2.3 轻量嵌入式与算法库阵营快速验证的利器生产环境的冒险Chroma应该是我见过最开发者友好的向量库一个 pip install 就能用数据存在本地文件夹里API 简单到 5 分钟能跑通一个语义搜索 Demo和 LangChain 的集成几乎是傻瓜式的。它适合原型验证、内部工具和体量很小的应用。但它在并发能力、崩溃恢复、过滤复杂度和数据安全上都还差些火候直接把它塞进生产链路后续大概率要重写数据访问层。LanceDB是无服务器模式的嵌入式向量库底层用列式存储格式 Lance天然支持版本化、回滚还能和 DuckDB 做 SQL 分析联动。它的场景更偏数据科学本地文件、多模态数据、需要和数据分析链路打通的工作流。如果你做的是数据分析平台或需要频繁更新数据集的研究项目它会很顺手如果是高并发的线上服务它还不是首选。FAISS严格说不是数据库而是 Meta 研究院开源的相似度搜索库但任何严肃的选型分析都不能漏了它因为它是向量索引算法的事实标杆Flat 精确检索、IVF、HNSW、PQ 这些算法在 FAISS 里都有标准实现而且支持 GPU 加速。拿它和上面的产品对比是不公平的——它没有网络服务、没有持久化、没有多租户、没有增量更新它是一个算法引擎不是数据库。但反过来如果你想完全掌控检索链路、自研一套检索服务FAISS 是最灵活的底座。我接触过不少大流量团队最终架构就是自己写一个薄服务层 FAISS用血泪换来极致的性能控制。3. 五个真正重要的对比维度性能、过滤、扩展、生态和账单产品摸底完了下面进入横向对比的核心部分。我不会给你一份灵魂跑分式的数据表因为每家测出来的成绩都会受数据分布、硬件配置、参数调优影响脱离场景比数字没有意义。我更想拆解的是五个选型维度——每个维度都对应一类你在真实项目中一定会遇到的决策点。3.1 性能不能只看 QPS召回率才是用户能感知的东西评估向量检索性能通常看四个指标召回率、QPS、延迟分位数p95/p99、写入吞吐。但很多团队只盯着 QPS这是本末倒置。召回率低意味着用户搜到的东西不对QPS 再高也没有意义。召回率和速度之间的平衡主要由索引类型和参数决定。HNSW 是目前最主流的索引它的关键参数是M每个节点的连接数、efConstruction建图时的搜索宽度和ef查询时的搜索宽度。M越大图越密召回越高但内存和建图时间也在涨efConstruction和ef越大查询越准但越慢。实测经验是默认参数通常偏向保守图密度不足以应对真实分布需要根据数据特征专门调。IVF 系索引则是先聚类后检索的思路nlist控制聚类中心数量nprobe控制查询时走访多少个桶。nprobe从 1 调到 20召回率可能从 70% 涨到 95%但延迟也会翻数倍。这条曲线需要你自己在自己数据上画出来。另一个经常被忽略的性能变量是向量量化。把 float32 向量转成 int8 或二值向量内存可以省到原来的一半甚至 1/32检索速度也更快代价是召回率下降几个百分点。很多产品在数据量上亿、内存告急时会用量化换取规模。我的建议是先跑 float32 基线再逐步测试不同量化级别对召回的影响不要在没看过基线之前就盲目上量化。提示任何公开跑分都只能作为初筛依据。最终决策前一定要用你自己的真实数据、真实查询模式跑一遍多参数组合的基准测试。我就见过某团队因为不加过滤条件跑分漂亮上线一加过滤 QPS 掉到跑分的 1/10。3.2 过滤与混合检索RAG 场景最容易翻车的点向量数据库选型里我最看重的一个功能是过滤——查找相似向量时按租户、文档类型、时间范围、标签等条件限定范围。几乎所有产品都说自己支持过滤但实现方式完全不同。低成本实现是后过滤先做向量近邻检索再对结果做标量条件过滤。如果过滤条件的命中率很低比如 1000 条结果里只有 3 条满足过滤条件最终返回的条数就不够系统只能放大召回量再过滤召回率会明显受损。好的实现是前过滤让标量条件参与索引查询路径检索时直接跳过不符合条件的节点。Qdrant 在这点上做得非常出色——它用 payload 索引 HNSW 结合过滤场景的性能衰退远小于同类产品。Milvus 也有类似机制但配置和理解成本更高需要熟悉它的分区、分区键等概念。pgvector 的办法最朴素向量索引和普通 B-Tree 索引在 SQL 里由优化器协调中小数据量下表现不错但大数据量下优化器可能走错路。混合检索向量召回 关键词召回再融合也是近两年的刚需。RAG 应用里纯靠向量检索经常丢失专有名词和精确匹配用 BM25 做补充能明显提升效果。Qdrant 支持 sparse 向量可以同时存密集向量和稀疏向量Milvus 2.4 加入了 BM25 全文检索支持Weaviate 和 Elasticsearch 原生支持混合检索pgvector 则要用 SQL 手写 union 和分数融合。如果你确定要走 RAG 路线混合检索支持程度应该作为一个一票否决项。3.3 数据规模与扩展性千万级和亿级不是同一个赛道向量数据库的扩展性关键看架构是不是从第一天就为分布式设计的。数据量在 100 万到 1000 万之间时其实是单机友好区HNSW 索引装进内存一台 64G 内存的机器绰绰有余选哪个库区别都不大。到了 5000 万以上内存压力开始逼近单机极限这时只有两条路要么量化降维要么上分布式集群。Milvus 的分布式做得最早也最彻底存算分离架构让它能独立扩展查询节点、数据节点和索引节点搭配对象存储之后理论上能到百亿级。Qdrant 的集群模式可以按 payload 字段做分片键也支持多副本但在多分片写入、动态再平衡这些功能上还在追赶。Weaviate 的集群能力更偏向复制 分级适合读多写少的场景。Pinecone 因为是托管服务扩容是自动的代价是你完全不知道它内部是怎么扩的。这里有个容易被忽略的点从单库迁到分布式集群不是改个配置就行往往要重新设计分片键、重新导数据、重写部分查询逻辑。所以选型时最好提前想清楚一年后数据量翻倍甚至翻十倍你的架构撑不撑得住撑不住的代价是多少人力3.4 开发体验与生态决定了团队能多快跑起来生态和开发体验直接决定项目的落地速度。我把它拆成四个子项SDK 成熟度、主流框架集成度、文档与社区、本地调试体验。SDK 层面Python 客户端是基本盘Milvus、Qdrant、Weaviate 都有很完善的 Python SDKMilvus 还额外覆盖 Java、Go、Node.js。如果你的服务端主语言是 Java 或 GoMilvus 和 Qdrant 更稳Weaviate 的客户端虽然也多但核心查询是 GraphQL后端同事需要额外学一套查询语法。框架集成层面Chroma 和 Qdrant 在 LangChain / LlamaIndex 的集成度最高基本是装个包就能用默认配置跑通。Milvus 的 LangChain 集成也在快速跟进但因为架构重配置会繁琐一些。pgvector 则要自己在 ORM 里写 SQL 查询灵活但费人工。本地调试体验也是隐性成本。Chroma 装完即用LanceDB 连数据库服务都不用起Milvus Lite 则能在本地嵌入式跑起来模拟完整 API。Qdrant 一个 Docker 容器搞定还自带一个能直接操作集合的 Web 面板。相比之下要完整模拟 Milvus 分布式环境要么装 Docker Compose 一整套要么连托管云本地调试的门槛高出不少。3.5 账单与运维自建和托管差的不是一点点成本这块我想先破除一个想当然的假设开源自建一定比云托管便宜。实际上总拥有成本TCO要算四笔账基础设施费用、运维人力、故障恢复成本、迁移成本。基础设施上自建方案的基础账单就是一组高内存节点的云服务器费用数据量大、量化没做好时内存是最大的开销。托管服务则按存储量、请求量和吞吐量计费它的坑在于流量涨起来之后账单可能比预期翻几倍。Pinecone 这类纯托管服务的计费模型在小数据量下很划算到了亿级向量高 QPS月账单会让你重新考虑开源方案。运维人力是很多人默认忽略的一笔。Milvus 集群自建光组件就有查询节点、数据节点、索引节点、etcd、消息队列、对象存储任何一环出问题都需要有人能排查。Qdrant 单机部署则简单到不像个数据库升级也几乎无感。Elasticsearch 更不用说了ES 集群调优本身就是一个专职岗位。所以成本维度的结论是把团队现有的运维能力当作选型因子。如果团队连 K8s 都玩不转就别为了省几万块服务器钱去自建 Milvus 集群如果团队有成熟的中间件运维经验托管方案的高昂月费反而变得不划算。4. 四个典型场景的推荐组合照着抄就行前面分析了很多为什么这一节直接给怎么选。我按过去一两年里最常见的四类真实项目给出推荐组合和理由。你可以把它当作初稿最终落地前用自己数据验证一遍。4.1 RAG 知识库问答首选 Qdrant重规模上 MilvusRAG 场景的特征是数据量多为几十万到几千万条查询模式高度依赖过滤按文档、按来源、按租户对混合检索的需求越来越强。这个场景我最推荐 Qdrant——它的过滤性能独一档单容器部署省心稀疏向量能同时覆盖关键词召回最后再用一个简单的 RRF 融合算法把两种分数合并效果非常稳。如果你的知识库文档量已经上亿或者要支持几十个业务线隔离、要实时写入删除那就得上 Milvus。它的分区机制和多租户能力、滚动物理删除、更强的写入通道都是为这种规模准备的。请注意我说的是上 Milvus而不是上 Milvus 集群——如果只是亿级读多写少单机大内存的 Milvus 也是可以接受的起点。4.2 图片 / 视频 / 多模态检索Milvus 或 Elasticsearch多模态检索场景的硬指标是数据量大、维度高通常是 512 到 1024 维、查询 QPS 不低、还要支持按标签或业务属性过滤。这种场景我优先推荐 Milvus它的大规模分布式能力和 DISKANN 索引把一部分数据放磁盘换容量是同类产品里做得最成熟的。选它之前先确认团队能接得住运维复杂度。如果团队本来就有 Elasticsearch而且检索业务要长期和关键词搜索共存比如电商搜商品、视频平台搜素材那么 ES 的 dense_vector 关键词 排序融合能力比新引入一套专用向量库更顺。代价是 ES 的资源开销会明显变大建议先在预发环境压一波负载再定。4.3 原型验证与内部工具Chroma / LanceDB / Milvus Lite快速验证概念时不要碰任何需要部署的服务。Chroma 是我的默认选择pip install 就能跑查询 API 简单到可以边开会边写 Demo。如果你的原型还会涉及数据分析、需要经常修改数据集并看历史版本LanceDB 更合适它那些列式存储和版本回滚的特性在这种场景下有奇效。Milvus Lite 也值得提一句它把 Milvus 的 API 完整搬到了嵌入式环境可以在你本机模拟以后真上 Milvus的代码路径。如果团队已经决定未来用 Milvus用 Lite 写原型能省掉后面迁移重写 SDK 的功夫。4.4 已有 PostgreSQL / Elasticsearch 的存量团队先别引入新组件每一个新组件都意味着一套新的学习成本、监控告警和故障面。如果团队已经有 PostgreSQL 在承载业务数据数据量又在千万级以内我最诚实的建议是先上 pgvector别急着引新库。它有着向量库里少见的和业务数据同一套事务体系的特性过滤条件可以和业务表 JOIN 在一起逻辑上非常干净。真的跑到了规模瓶颈再把这部分数据迁到 Qdrant 或 Milvus 也不迟届时你已经有了更清晰的数据模型认知。Elasticsearch 存量团队同理ES 自带向量能力够用的话完全没有必要再架一个专用向量数据库除非你真的需要亿级规模下的极致向量检索性能。5. 我在真实项目里踩过的坑参数、过滤和数据翻倍最后这部分是我希望自己当年入行时能看到的内容。下面每一个坑都不是理论可能性而是我和身边团队真实付出过学费的教训。5.1 HNSW 默认参数不是出厂最优最早做一个 RAG 项目时我们把文档向量灌进向量库用的是默认索引参数本地测试召回效果还行就直接上了预发。结果业务同事反馈很多明显相关的问题答不对一查才发现是 HNSW 的efConstruction和ef都偏小索引图建得不够密高维数据下召回率只有 70% 出头。解决办法是在自己的数据分布上做参数扫描。我现在的标准流程是固定M32efConstruction从 100 扫到 400ef从 64 扫到 512用一批标注过的查询记录画出EF 值 vs 召回率 vs p95 延迟的曲线再挑一个甜点区。别偷懒这个步骤值得做因为它直接影响用户的 search 体验。5.2 过滤条件一加QPS 掉了 90%另一个项目做的是带租户隔离的语义搜索。选型时跑了无过滤的基准单机 QPS 能到几千结果上线后每个请求都带租户过滤QPS 直接掉到原来的十分之一原因就是检索链路把过滤放在了近邻检索之后——先捞出一大批相似向量再大批量丢弃不符合租户条件的向量等于每一条查询都在做无效功。这个坑的教训是在评估阶段就一定要带上最典型的过滤条件跑基准而且要用真实命中率偏低的过滤词去压测。不同产品在带过滤场景下的表现差距比无过滤场景大得多这也是为什么我在前面的分析里反复强调 Qdrant 这类前过滤实现的价值。5.3 从千万到数亿单机迁移集群的沉重代价我最想提醒的一句话是选型的时候不要把当前数据量当作唯一依据要把一年后的数据量也写进需求。有个朋友的项目最开始用嵌入式方案 单机数据量到了 3000 万时还能扛后来业务增长到数亿内存爆了不得不迁到分布式集群。结果发现导出数据格式不兼容、分片键要重新设计、查询参数全部重新调优整个迁移花了团队两个多月。如果当初在架构评审时就把一年后的规模考虑在内哪怕先用单机也在写数据访问层时加一层抽象、提前验证导出机制迁移成本至少砍半。向量数据库的迁移永远比重建一个更痛苦因为索引内容不是简单的数据复制很多库的备份格式互不通用。5.4 人员成本才是最大的变量别只算服务器账单最后一个坑偏组织层面。我们曾在一轮选型里比较中意某款分布式向量库性能指标漂亮开源免费服务器预算也控制得住。但真到了运维阶段才发现团队没人熟悉它的组件体系出了故障连日志都看不懂每次排查都要现查文档一锅锅地消耗开发时间。最后折算下来隐性成本比直接用托管方案还高。所以我在每一次选型评审里都会加一个问题如果负责这个系统的人明天离职你的团队需要多久才能接手答案是一两周的产品远比性能好 20%但没人会维护的产品值得选。最后再分享一个我个人的习惯无论选了哪个向量数据库我都会把数据访问层封装成一套独立接口并在方案里预留第二候选。技术选型永远存在不确定性而有退路本身就是团队最值钱的一份保险。
阅读完成 · 觉得有帮助？
