月活11亿的Reddit ，怎么选向量数据库：Pgvector、Redis、Milvus、Qdrant

业务团队可能说他们想要个负重一吨，时速两百公里的马车……

现如今，借助向量检索能力，实现基于语义相似度的智能搜索，已经是所有电商、推荐、社区平台技术架构的重要一环。

作为拥有约 1.08 亿日活、 11 亿月活用户的兴趣内容社区平台， Reddit自然也不例外。

自2024 年起，Reddit 各个团队就已经开始用不少方案来做近似最近邻（ANN）向量搜索。这个过程中，有用过谷歌的 Vertex AI 向量搜索， 也试过用Apache Solr 的 ANN 向量搜索处理一些大数据集，还有在垂直扩展的边缘节点里部署 Facebook 的 FAISS 库，专门应对小数据集。

但是，随着越来越多团队和业务对向量检索的需求持续增加，建立统一的向量数据库infra底座就随之被提上了日程。

整体来说， Reddit的整个向量数据库选型分四步走：收集团队需求背景、定性评估候选方案、定量测试头部选手、敲定最终答案。这里面，每一环都有不同的坑，以下复盘可以供所有人参考。

当然，文章不是要评判哪款向量数据库天下第一，测试也不会符合所有场景的需求。以下仅代表 Reddit的业务选型逻辑以及优先级排序。

01 

收集团队需求

最一开始， Reddit对想用ANN 向量搜索的团队，收集了三方面关键信息：

• 功能需求（比如：能不能同时做向量和关键词搜索？支持标签检索吗？能不能按非向量属性过滤？）

• 非功能需求（比如：能不能存 10 亿级向量？P99 延迟能不能控制在 100 毫秒以内？）

• 团队已经在用或者感兴趣的向量数据库

跟团队聊清楚需求其实不简单。

很多团队会照着自己现在的解决办法说需求，然后成功把所有人带偏。

举个例子，有个团队本来在用 FAISS 做 ANN 向量搜索，基于这个背景，他们说新方案必须每次搜索能高效返回 1 万条结果。

一万条？用户难道要没日没夜24小时都住在 Reddit看帖子吗？

进一步追问才知道，之所以要 1 万条，是因为 FAISS 不支持语义检索的同时做过滤，然后他们只能先拿大量语义召回结果，做事后筛选，来保证召回率。

所以，团队的真实需求根本不是一万条数据，而是高效过滤方案。而且，要是能先过滤，再做语义检索，其实也能节省下大量的语义检索成本。

梳理清楚需求之后，接下来盘点大家都在用什么产品也很重要：一般有一个团队觉得某款方案好用，那这款就有可能在全公司推广；如果大家都吐槽某款，那直接 pass 就行。

02 

定性评估候选方案

以团队关注的方案为基础，我们按这三步定性评估，找出最贴合需求的：

1. 研究每个方案，对照需求的权重打分，看方案能满足多少需求
2. 按定性标准和讨论结果，删掉一些不合适的方案
3. 选出前几名，进入定量测试阶段

我们一开始的候选清单有这些：

• 纯向量检索产品：Milvus、Qdrant、Weaviate、OpenSearch、Vespa、Pinecone

• 带有向量检索能力的其他数据库：Pgvector（本来就用 PostgreSQL 当关系型数据库）、Redis（本来就用它做键值存储和缓存）Cassandra（已用于非 ANN 搜索）Solr（本来用它做词法搜索，之前试过用它做向量搜索）、Vertex AI（已经在用来做 ANN 向量搜索）

接下来，我们把所有团队提的功能、非功能需求，再加上一些符合我们工程价值观和目标的约束条件，都列成表格行，给每项需求定个权重（1-3 分）。

然后给每个候选方案打分，按 0-3 分评它满足每项需求的程度（如下表）。打分虽然有点主观，但我们选了一个基准方案，给出打分例子和理由，让评估的人都照着参考。

以下是打分规则：

• 0 分：不支持，也没证据表明能支持

• 1 分：勉强支持，或者支持得不够好

• 2 分：支持得还不错，能满足基本需求

• 3 分：支持得特别好，比同类方案都强

不过，要注意有些能力的选项权重的重要性可能已经超过了0-3分的范畴，而是一个选型的硬约束。比如对Reddit来说，这个硬约束就是是否开源。

因为，向量数据库是一个还相对比较新的事物，需要项目方和客户一同打磨，一同进步，开源让客户自身也能深度参与、贡献代码的方案，这样一旦遇到问题，也自主快速修复。也是因为这个原因，Vertex AI、Pinecone这两个选项在一开始被Reddit排除在外。

综合以上条件，以下是具体打分结果

最后，每个方案的总分会用方案在某项需求的得分乘以这项需求的权重，再加起来（比如 Qdrant 在 “重排序 / 分数合并” 这一项得 3 分，权重是 2，那这项就是 6 分，所有项都这么算再求和）。

注意：这个总分是用来为下一步筛选提供候选集的，不是最终决策的唯一依据。

为什么说这个得分不能作为最终选型依据，一个很重要的点是在于有些功能，大家看起来都有，但怎么实现的，实际体验如何可能天差地别，有时候，一些所谓的3分选手，可能在体验上并不见得比1分选手做的更好。

因此，对于一些最重要的指标，团队必须要做实际的定量测试之后，才知道合不合适。

定量测试则围绕以下几个点重点展开：

• 扩展性和可靠性：得有其他公司用这款方案支撑 1 亿级甚至 10 亿级向量的案例

• 社区生态：方案得有活跃的社区，在这个快速发展的领域里有足够的势头

• 元数据类型丰富、过滤功能强：能支持日期、布尔值等多种过滤方式，适配更多使用场景

• 支持多种索引类型（不只是 HNSW 或 DiskANN）：能根据Reddit不同的使用场景，优化性能

考虑到上面的初步评测结果，Qdrant和Milvus评分接近，且大幅领先其他产品，而定量测试又要花费大量的时间、预算、精力，因此我们定量测试阶段，就重点选了这两家产品。

正好，Qdrant 和 Milvus 的架构差异也很有意思，可以对比：

• Qdrant：同构节点架构，一个节点就承担 ANN 向量数据库的所有操作

• Milvus：异构节点架构，查询、索引、数据写入、代理这些功能，都由不同的节点来做

03 

定量测试头部选手

我们想通过定量测试搞清楚：哪种方案部署起来简单（看文档好不好用）？哪种方案运行起来省心（看弹性和成熟度）？哪种方案在我们关注的场景和规模下性能更好？

于是我们做了这些：

• 收集了三个不同使用场景的文档和查询向量数据集

• 在 Kubernetes 里给每个方案分配了差不多的资源

• 把文档数据导入每个方案

• 用 Grafana 的 K6 工具发相同的查询负载：先让系统预热，再升到目标吞吐量（比如 100 QPS）

测试重点看这些：

• 吞吐量：找到每个方案的性能临界点

• 吞吐量和延迟的关系

• 负载期间节点挂了之后的表现（错误率、延迟变化等）

• 过滤功能对延迟的影响

另外，我们还做了些简单的 “能用 / 不能用” 测试，验证文档里说的功能是不是真的能用（比如更新插入、删除、按 ID 查询、用户管理这些），同时感受一下这些 API 好不好用。

这次测试用的是 Milvus v2.4 和 Qdrant v1.12。因为时间有限，我们没把所有索引配置都调一遍，只给两个方案设了差不多的配置（优先保证高 ANN 召回率），重点测 HNSW 索引的性能。CPU 和内存资源也给得差不多。

测试下来，我们发现两款方案有不少有意思的差异。下面这些实验，用的都是约 3.4 亿条 Reddit 帖子向量（每条 384 维），HNSW 索引的参数是 M=16、efConstruction=100。

第一个实验：同样的查询吞吐量（100 QPS，不做写入操作）。

可以看到，加了过滤条件之后，Milvus 的延迟比 Qdrant 受影响更大。

（图表标题：带过滤条件的帖子查询延迟 注：延迟越低越好）

第二个实验：吞吐量不变的情况下，写入期间 100 QPS 的帖子查询延迟。

可以看到，Qdrant 的写入操作对查询负载的影响，比 Milvus 大得多（如下图）。这应该是架构的问题：Milvus 的写入操作有专门的节点负责，和处理查询的节点是分开的；而 Qdrant 是同一个节点又要处理写入，又要处理查询。

（图表标题：写入期间 100 QPS 的帖子查询延迟 注：延迟越低越好）

第三个实验：测试按属性控制结果多样性（比如每个子版块的结果不超过 N 条）。

可以看到，同样 100 QPS 的吞吐量，Milvus 的延迟比 Qdrant 高。

（图表标题：带结果多样性的帖子查询延迟 注：延迟越低越好）

此外，我们还测试了增加数据副本数（复制因子 RF 从 1 升到 2）之后的扩展效果。一开始测 RF=1 的时候，在延迟达标的前提下，Qdrant 能支撑的吞吐量比 Milvus 高（更高的 QPS 没显示，因为测试时出现错误，没跑完）。

（图表标题：Qdrant 帖子查询 RF=1 不同吞吐量下的延迟）

（图表标题：Milvus 帖子查询 RF=1 不同吞吐量下的延迟 ）

但把复制因子升到 2 之后，Qdrant 的 P99 延迟虽然有改善，可 Milvus 能在延迟达标的情况下，支撑更高的吞吐量（Qdrant 的 400 QPS 没显示，因为延迟太高还出了错，测试没跑完）。

（图表标题：Milvus 帖子查询 RF=2 不同吞吐量下的延迟）

（图表标题：Qdrant 帖子查询 RF=2 不同吞吐量下的延迟 注：没法稳定超过 300 QPS）

因为时间不够，我们没在自己的数据集上对比两款方案的 ANN 召回率，但参考了ann-benchmarks.com网站上公开数据集的测试结果。

04 

敲定最终方案

性能方面，没怎么调优、只使用 HNSW 索引的情况下，Qdrant 的延迟表现看起来的确比 Milvus 好。但 Milvus 增加副本数之后，扩展性更优，而且因为是多节点架构，写入和查询的相互影响更小。

运维方面，虽然 Milvus 的架构更复杂（毕竟是为海量数据打造的产品，用了多节点类型，还得依赖 Kafka 这种外部预写日志和 etcd 这种元数据存储），但要是两款方案都出了问题，我们调试、修复 Milvus 反而更顺手。

另外，Milvus 增加数据集的复制因子时，能自动做负载均衡；而开源版的 Qdrant 得手动创建或删除分片才能提升复制因子 —— 要么我们自己开发这个功能，要么就得用非开源版。

整体来说，Milvus 比 Qdrant 更适配 Reddit 的技术体系，也和Reddit 的技术栈更像。Milvus 是用 Golang 写的，这是Reddit 首选的后端编程语言，所以给它贡献代码比给 Rust 写的 Qdrant 容易。而且 Milvus 开源版本的迭代速度比 Qdrant 快，满足的核心需求也更多。

最后，两款方案其实都满足了我们大部分需求，但考虑到Reddit 是一个依然在高速增长的平台，且未来的数据体量与运维难度还将节节攀升，选择Milvus 的更强扩展性，能让整体运行更放心，也更适配Reddit 公司的情况。

虽然没来得及测 Vespa 和 Weaviate 有点可惜，但就算测了，估计也不会选 ——Vespa 是用 Java 写的，和Reddit 的技术栈不太搭；Weaviate 和 Qdrant 一样是单节点架构，Qdrant都做不到的事情，Weaviate 自然也不符合我们的需求。

05 

尾声

最后想多念叨两句实操里的小提醒，算不上标准答案，更像是踩过坑后的真心建议：

面对需求别着急 照单全收，多刨根问底两句，别被已有的解决方案框住思路，避免带着偏见做判断；

给候选方案打分没问题，但分数只是帮你理清核心需求的参考，可别当成唯一的 决策依据，可能会被厂商天花乱坠的文档给骗了；

定量测试性能的时候，也别忘了多留心，这个方案好不好部署、调试起来顺不顺手、后续维护会不会费劲，这影响所有人的实际使用体验。选型终究是门 平衡术，维护成本、使用便捷性和性能都得放进考量里，没必要死磕 某一个特殊环境下的所谓性能最优这一个指标。

多站在实际使用和长期维护的角度想想，反而能少走不少弯路。

文章来自于微信公众号 “Zilliz”，作者 “Zilliz”