适用读者：要决定"向量存哪"的人。
前置：S13-A02。
覆盖旧文：569（ES vs Pinecone 等，133 点）。
上一篇：S13-A02 · 语义搜索与混合检索：BM25 + kNN
下一篇：S13-A04 · 聚合搜索设计与 MongoDB。

---

1. 一句话结论

选型的核心不是"谁检索快"，而是"你要不要同时保留关键词检索、以及团队能不能多运维一套系统"。

方案	优势	代价
ES（dense_vector）	关键词 + 向量一套系统、已有运维	向量能力不如专用库（功能/规模）
专用向量库（Milvus/Qdrant/Chroma）	向量性能与规模更强	多一套系统、需双写/同步
pgvector（PostgreSQL）	事务 + 向量同库	规模上限较低
Redis Stack	低延迟、已有 Redis	内存成本高

---

2. 决策树

已有 ES 且数据量 < 千万级向量？
├── 是 → 先用 ES（一套系统，够用）
└── 否 → 向量规模/延迟是核心指标？
        ├── 是 → 专用向量库（Milvus/Qdrant）
        └── 否 → pgvector / Redis Stack

判据："向量检索是核心业务还是辅助能力？" 辅助 → 复用现有系统；核心 → 专用库。

---

3. 四条容易忽略的成本

成本	说明
多一套同步	向量库的数据同样要同步（与 A01 同源问题）
内存	HNSW 索引常驻内存，规模大时很贵
运维	备份/监控/升级各一套
一致性	向量与原文/元数据要一起更新

"两套系统 = 两倍一致性问题" 是本系列最该记住的一句。

---

4. 迁移与回滚

阶段	动作
评估	用真实查询集对比召回率/延迟
双跑	新库旁路写入，离线评估
切换	按流量灰度
回滚	保留旧路径开关

---

5. 五个误区

误区	真相
"专用库一定更好"	取决于规模与是否要关键词
"ES 向量不能用"	中小规模完全够
"加个向量库不影响架构"	多一套同步/运维/一致性
"只看 QPS 选型"	还要看召回质量
"向量库能替代搜索引擎"	关键词/过滤/聚合它更弱

---

6. 自检（架构师版）

1. 四种方案的优劣？
2. 决策树的两个判断点？
3. 四条隐性成本？
4. 为什么"两套系统=两倍一致性问题"？
5. 迁移时怎么降低风险？

---

7. 下一篇

S13-A04 · 聚合搜索设计与文档库（MongoDB）

选型讲完，最后一篇：多源聚合怎么设计，以及 MongoDB 适合什么。

---

本篇属于系列《S13 · 搜索与文档存储》。旧文来源：A-569。