3、选型第一关：数据规模与性能：百万级、千万级、亿级向量场景下的吞吐量与延迟对比，我踩过的性能坑。

很多朋友选向量数据库，上来就问：“哪个最快？”

说实话，这个问题没法直接回答。你想想看，百万级和亿级数据量，对系统的要求完全是两码事。我见过不少团队，拿着小规模测试的数据去推演生产环境，结果上线就崩。

今天咱们就聊聊，不同数据规模下，吞吐量和延迟到底怎么变。顺便说说我踩过的那些坑。

3.1 数据规模的三道坎

我个人习惯把向量数据规模分成三个档位：

规模等级	向量数量	典型场景
百万级	10万 ~ 500万	小型推荐、图片去重、小规模语义搜索
千万级	500万 ~ 5000万	中型搜索、用户画像匹配、风控
亿级	5000万 ~ 10亿+	大规模搜索引擎、全量商品推荐、社交网络

每个档位，选型策略完全不同。别想着一个方案打天下，那会出大问题。

3.2 吞吐量与延迟：鱼和熊掌

吞吐量（QPS）和延迟（Latency），本质上是矛盾的。你追求高并发，单个请求的处理时间就会变长。反过来，你想让每个请求都快，并发能力就得降下来。

我举个例子。同样是 1000 万条 128 维向量，用 HNSW 索引：

• 追求低延迟：把 ef_search 设小，比如 64。单次查询延迟能压到 5ms 以内，但 QPS 可能只有 200。
• 追求高吞吐：把 ef_search 设大，比如 256。QPS 能冲到 2000，但延迟会涨到 20ms 以上。

你看，这就是个 trade-off。没有的好，只有适合不适合。

3.3 百万级场景：别想太多

百万级数据量，说实话，大部分向量数据库都能搞定。我建议你关注两点：

1. 索引构建速度：别等几个小时索引还没建好。
2. 资源占用：别为了 100 万向量，配个 64G 内存的机器。

我在项目中遇到过，有人用 FAISS 搭了个 200 万向量的服务，结果每次重启都要重新建索引，耗时 40 分钟。后来换成支持持久化的 Milvus，问题就解决了。

3.4 千万级场景：开始有挑战了

到了千万级，事情就复杂了。你会发现，同样的查询，延迟开始不稳定。有时候 10ms，有时候 100ms。

为什么会这样？

因为索引结构开始受到内存和磁盘 I/O 的影响。HNSW 这种图索引，在千万级下，内存占用会变得很大。我算过一笔账：

• 1000 万条 768 维向量（比如 BERT 生成的），原始数据占 30GB。
• 加上 HNSW 的图结构，内存占用轻松超过 60GB。

这时候，如果你用单机方案，内存很容易爆。我踩过这个坑。当时选了个单机版 Milvus，数据量涨到 2000 万，服务直接 OOM 了。后来不得不迁移到分布式方案，折腾了两周。

3.5 亿级场景：真正的考验

亿级向量，说实话，能选的方案就不多了。你需要考虑：

• 分布式分片：数据必须打散到多台机器上。
• 索引分区：单个索引文件不能太大，否则查询效率急剧下降。
• 资源隔离：写入和查询要分开，别互相影响。

我参与过一个项目，10 亿条 128 维向量，要求 P99 延迟在 50ms 以内。我们试了好几种方案：

方案	QPS	P99 延迟	机器数
单机 HNSW	500	120ms	1 台 128G
分布式 IVFPQ	3000	45ms	4 台 64G
分布式 HNSW	2000	30ms	8 台 64G

最终我们选了分布式 IVFPQ。虽然召回率比 HNSW 低一点，但性价比高，延迟也达标。

3.6 我踩过的性能坑

这些年，我在性能上栽过不少跟头。挑几个典型的说说：

• 坑一：索引参数没调。默认参数跑小数据没问题，数据一涨，性能直接崩。HNSW 的 M 和 efConstruction，IVF 的 nlist，这些参数必须根据数据量调。
• 坑二：忽略了预热。有些索引需要预热才能达到最佳性能。我试过，没预热的时候 P99 延迟 200ms，预热后降到 20ms。
• 坑三：并发模型选错。Python 的 GIL 是个大问题。用多线程做向量查询，性能还不如单线程。后来改成多进程 + 异步，才把吞吐量提上去。

3.7 一张图看懂选型逻辑

下面这张图，是我自己总结的选型决策流程。每次做新项目，我都会拿出来对照一下。

3.8 总结一下

选型第一关，说白了就是搞清楚你的数据规模。别拿百万级的经验去套亿级场景，也别为了亿级场景过度设计百万级的方案。

我个人的建议是：

• 百万级：随便选，关注运维成本。
• 千万级：认真评估内存和磁盘，做好参数调优。
• 亿级：分布式是必须的，做好分片和资源隔离。

嗯，今天就聊到这儿。记住，性能不是选出来的，是测出来的。拿到数据，先跑个 benchmark，比什么都强。