向量数据库选型——性能、成本与适用场景
向量数据库的选型方法。从数据与负载边界出发，对比四类主流 ANN 索引的权衡与产品能力，给出成本模型与场景决策路径，供结合查询分布验证。
一 选型前提：先界定数据与负载的四个边界
向量检索（ANN 近似最近邻）的选型不是"哪个数据库最快"，而是四组边界条件下的取舍：规模（向量条数）、维度与距离度量、负载形态（在线低延迟 / 离线批量 / 混合过滤）、以及预算与运维能力。本文按"能力光谱 → 成本模型 → 场景决策树 → 验证方法"展开。
二 四类主流 ANN 索引的原理与权衡
| 索引 | 原理 | 召回率 | 构建速度 | 内存占用 | 过滤场景表现 |
|---|---|---|---|---|---|
| Flat（暴力） | 全量计算距离 | 100% | 无构建 | 高（全量驻留） | 最强（无索引失效问题） |
| HNSW | 多层跳表 + 近邻图 | 0.90-0.99 | 中（O(n log n)） | 高（图结构 + 向量全量） | 中（前置过滤会剪断图） |
| IVF（家族：IVF-PQ 等） | 倒排聚类粗筛 + 细搜 | 0.80-0.95 | 快（聚类一次） | 中低（PQ 压缩） | 好（分桶内过滤代价小） |
| DiskANN / 磁盘型 | 图索引在磁盘 + 热缓存 | 0.90-0.98 | 慢（需磁盘排序） | 极低（向量在 NVMe） | 好（亿级规模首选） |
关键认识：所有"向量数据库"的底层都是这四类索引，商业 / 开源产品差异主要在于：索引实现（HNSW 调优 / PQ 变体）、过滤下推能力、多向量与混合搜索（标量 + 向量 + 全文）、部署形态（单机 / 分布式 / 托管）。选数据库本质是选"索引 + 过滤 + 运维"的组合。
三 候选产品能力光谱
| 类型 | 代表 | 强项 | 弱项 |
|---|---|---|---|
| 独立向量库（开源单机） | Qdrant、Milvus、Weaviate、Chroma、LanceDB | 部署轻、索引调参细、过滤强（Qdrant payload 过滤、Milvus 标量混合） | 大规模需集群版图（Qdrant Cluster / Milvus 分布式版），运维靠自己 |
| 向量库（开源分布式） | Milvus 2.x、TigerGraph 系、Vespa | 亿级 + 高并发、存算分离、冷热分层 | 组件多（etcd / minio / pulsar），运维门槛高 |
| 搜索引擎扩展 | Elasticsearch / OpenSearch 的 k-NN /NNSQL、Vespa、Typesense | 已有倒排全文，混合检索一站搞定；法律、日志检索等既有生态成熟 | 向量性能上限低于专业库；内存占用重 |
| 关系数据库向量扩展 | PostgreSQL + pgvector、TimescaleDB、MariaDB 10.11+、Oracle | 与业务数据同库，JOIN / 事务 / 过滤最强；运维零新增 | 单机上限（千万级内可用），HNSW 构建占用高；超大规模受限 |
| 托管服务 | AWS OpenSearch / Pinecone / GCP Vertex AI Vector Search / Azure AI Search | 免运维、弹性付费、SLA | 单实例成本天花板高；锁定与网络延迟；数据不出境合规考量 |
| 嵌入式 / 本地 | LanceDB、Chroma、sqlite-vec、Dragonfly / Faiss 直接嵌入 | 原型最快、无网络开销、边缘可跑 | 单机容量上限、无高可用 |
四 成本模型：非向量部分占比更高
向量库的 TCO 常见拆法（以 1 亿条 768 维 float32 为例，约 300GB 原始向量）：
- 内存成本：HNSW 全量驻留需 300-500GB RAM（含图结构 + M 边 + 缓存），单大节点内存月成本常超向量存储成本本身；IVF-PQ 压缩到 1/8-1/16，内存成本骤降，代价是召回率。
- 磁盘成本：DiskANN 路线把向量放 NVMe，内存成本降为"热层"大小（16-64GB），但要求 NVMe 高随机读 IOPS——云盘按 IOPS 计费后，磁盘成本可能反超内存。
- 构建 / 重建成本：HNSW 重建是分钟-小时级负载；数据高频更新（嵌入流式刷新）时，"增量重建窗口"是隐藏成本。
- 嵌入计算成本：常被忽略的"向量库"上游——每次新增 / 更新都要调嵌入模型。日志场景嵌入成本往往超过向量库本身。
- 复制 / 副本成本：高可用要 3 副本，HNSW 全量驻留路线下，副本是 RAM 的直接 3 倍。
五 场景决策参考
| 场景画像 | 推荐路径 | 理由 |
|---|---|---|
| 原型 / 桌面应用 / 边缘 | LanceDB / Chroma / sqlite-vec + Faiss | 零运维、本地跑、够用即停 |
| 千万级内 + 强业务 JOIN（客服知识库、风控） | PostgreSQL + pgvector（或同库向量扩展） | 事务 + 事务 + 过滤同库，运维零新增，千万内 HNSW 性能足够 |
| 千万至亿级 + 重混合过滤（商品搜索、个性化） | Qdrant 集群 / Milvus / Weaviate | 独立库索引调参深、过滤下推强，横向扩算力 |
| 亿级以上 + 高密度过滤（电商、法律检索） | Milvus 分布式 / Vespa / 自研 DiskANN on NVMe | 存算分离 + 磁盘型索引摊薄 RAM 成本 |
| 已有 ES/OpenSearch 栈 + 全文混合 | 原地开 k-NN，或加 Qdrant 做第二套向量 | 混合搜索（BM25 + 向量重排）在搜索引擎里最顺 |
| 不想运维 + 预算充足 | 托管（Pinecone / 云厂商） | 买 SLA 和弹性，单实例成本可接受时最省人 |
注意"先 pgvector、后独立库"的迁移路径：多数业务从关系库向量扩展起步，到千万级或延迟要求上来后再迁独立库，两条路线的数据格式（嵌入向量 + 元数据）天然可平移，迁移成本主要是索引重建时间。
六 验证：用真实数据跑三类基准测自己的分布
- 召回延迟曲线：固定 QPS，扫 top_k = 10/50/200，记录 P50/P99 延迟与召回率（对 brute-force 真值算）。选型不是看"最快"，是看"在目标延迟内最高召回"。
- 过滤压力测试：用真实查询的过滤谓词（而非均匀随机过滤）打 5% / 50% / 95% 选择率的三档——高选择率查询下 HNSW 可能性能骤降，IVF / 位图混合路线反而稳。这一项能直接淘汰不适合自己查询分布的方案。
- 构建与更新压测：按真实新增速率（条/分钟）跑 24 小时，看索引是否退化、延迟是否漂移、重建窗口是否可接受。
第三方基准（ANN-Benchmarks、VectorDBBench）可作起点，但对"带过滤的真实查询分布"没有代表性——自己数据自己的分布才是终裁。
七 误判与规避
| 误判 | 正确视角 |
|---|---|
| "向量库 = 更快的 L2" | ANN 是召回率-延迟-内存的三角权衡，"快"不绝对，只对特定数据分布成立 |
| "维度越高效果越好" | 高维嵌入 + 暴力搜索，延迟按 n·d 线性涨；768 vs 1536 维对多数检索任务召回增益有限，先测再说 |
| "小数据用 HNSW 无所谓" | 100 万条内，Flat（暴力）召回 100% 且延迟常比 HNSW 更稳；"不上 HNSW"是合理选项，不是偷懒 |
| "过滤是查完再筛" | 后置过滤在小选择率下会返回远少于 top_k 的结果；要么前置过滤（走索引时带谓词），要么召回 5-10 倍 top_k 再筛 |
| "一个向量库管所有业务" | 不同业务查询分布（top_k / 选择率 / 维度）差异大，混用一套索引参数是性能低谷来源；分 collection / 分库更稳 |
| "托管一定省心" | 托管的"省心"买的是运维，不是成本——单实例 RAM 预留 + 读写分离，账单常超过同规模自建 2-3 倍 |
八 落地清单
- 先写下四参数：条数量级 / 维度 / 目标 P99 延迟 / 月新增速率——这四个数不写清，选型是玄学
- 三档选择率过滤压测，用自己真实查询分布
- 索引参数从默认开始调（HNSW 的 M、ef / IVF 的 nlist、nprobe），记录召回-延迟曲线后做帕累托裁剪
- 副本与备份策略定稿：索引可重建（嵌入向量是源数据，丢了可从源库重嵌入重建），备份策略以"源数据"为中心
- 设 3 个月后再看一次：条数、查询分布、延迟分布三个数各变了多少，索引是否要换
一句话收束：向量库选型是"数据分布 × 预算"的函数，不是"品牌 × 跑分"的函数。先量化自己的分布，再拿三类基准打自己的数据，让数字说话。
九 真实案例回顾
案例一：in-memory HNSW 上线时召回很好，三个月后向量数过了 1000 万，启动时间从 40 秒涨到 9 分钟，节点重启窗口拖到不可接受——如果选型时把"规模上限"写进决策表，当时就会直接选 mmap 方案或 DiskANN。案例二：把"RAG 效果不好"归给向量库，调了一圈索引参数都没用，最后发现是分块把表格切碎了——向量库是检索链的一环而不是全部，选库之前先把分块和查询词做好，否则换什么库都白搭。