Booking.com 把向量数据库给换了，这次选型过程挺有参考价值

很多公司在做 RAG 落地时，最容易在向量数据库这一环掉坑里。Booking.com 这种量级的公司在选型时，关注的绝对不是简单的查询速度，而是那种在极大规模数据下依然能保持稳定且低成本的运维能力。

他们这次在选型时把重点放在了几个关键维度上，我觉得最核心的是对内存管理和索引更新效率的权衡。很多号称高性能的数据库在数据量达到千万甚至亿级后，内存占用会像滚雪球一样爆炸，导致成本失控。

对于想在生产环境部署向量检索的开发者，可以参考他们筛选的几个核心考量点：

• 索引构建的资源消耗： 很多数据库在重新构建索引时会把 CPU 撑满，直接影响在线服务的响应时间，必须选择支持增量更新且资源占用可控的方案。
• 查询延迟的稳定性： P99 延迟比平均延迟重要得多。在极高并发下，能否保证绝大多数请求都在几十毫秒内返回，决定了用户体验。
• 水平扩展的复杂度： 增加节点时是否需要全量迁移数据？如果扩容需要停机或者导致长时间的索引重构，那在实际业务中几乎不可行。
• 内存与磁盘的混合存储： 全内存方案太贵，纯磁盘方案太慢，能灵活配置缓存机制的数据库才是真实用。

在实际操作中，如果你是从零开始搭建，建议先用简单的轻量级方案跑通 MVP，但一旦进入实战阶段，必须对数据规模做压力测试。比如你可以尝试用以下逻辑来验证一个向量数据库是否能承载你的业务量：

# 模拟大规模数据导入测试（伪代码）
# 1. 导入 100万条向量数据
# 2. 记录索引构建时间与内存峰值
# 3. 使用 jMeter 或 k6 模拟 1000 QPS 的并发查询
# 4. 观察 P99 延迟是否在 100ms 以内

这种规模的选型其实就是一场关于“成本 vs 性能”的博弈。不要迷信任何 Benchmark 跑分，因为真实的业务分布和查询模式永远比实验室数据复杂得多。