向量库选型与全景

36.1 全景表格

Spring AI 官方文档列出的实现分三类：云托管服务、可自建的开源存储、以及仅测试用的内存实现。表中 starter 遵循统一的命名约定：spring-ai-starter-vector-store-<名称>。

实现	类型	部署方式	适用场景
Azure AI Search	云搜索服务	云托管	Azure 生态、需要全文+向量混合检索
Azure Cosmos DB	云文档数据库	云托管	外部模块（Cosmos DB 团队维护）、Azure 生态
Bedrock Knowledge Base	云托管 RAG 服务	云托管	只读向量库，文档摄取由服务内部处理
Pinecone	专用向量库	云托管	不想运维、数据量弹性增长
MongoDB Atlas	云文档数据库	云托管	已在用 Atlas、文档型数据
Cassandra + JVector	分布式数据库	自建或 Astra DB	海量数据、高可用写入
Milvus	专用向量库	自建或 Zilliz 云	百万级以上、检索性能优先
Qdrant	专用向量库	自建或 Qdrant 云	HNSW 检索、元数据过滤复杂
Weaviate	专用向量库	自建或 Weaviate 云	十亿级对象、多模态数据
Chroma	专用向量库	自建或 Chroma Cloud	原型验证、轻量起步
PGvector	PostgreSQL 扩展	自建	已有 PostgreSQL、数据同库
Redis	内存存储+搜索模块	自建或 Redis Cloud	低延迟、高频检索、语义缓存
MariaDB	关系数据库	自建	已有 MariaDB 技术栈
Oracle 23ai	关系数据库	自建	企业已有 Oracle 资产
Elasticsearch	搜索与分析引擎	自建或 Elastic Cloud	全文+向量混合搜索
OpenSearch	搜索与分析引擎	自建或 AWS 托管	Elasticsearch 分支、AWS 生态
Typesense	搜索引擎	自建	拼写容错、亚 50ms 检索
Couchbase	JSON 文档数据库	自建	文档+向量一体
Neo4j	图数据库	自建或 AuraDB	知识图谱+向量结合
GemFire	内存键值存储	自建（VMware Tanzu）	实时高并发读取
S3 Vector Store	对象存储	云托管（AWS）	2.0 新增、向量与对象存储一体
SimpleVectorStore	内存实现	无	仅测试演示，禁止生产

这张表看着长，背后的分类逻辑只有三类。

36.2 三条技术路线

专用向量数据库。 Milvus、Qdrant、Weaviate、Pinecone、Chroma 都是为向量检索设计的。索引算法、分片、标量过滤都围绕向量优化，检索性能最强。代价是多一套独立系统要部署、监控、备份。

传统数据库加向量能力。 PGvector、Redis、MariaDB、Oracle、MongoDB、Cassandra 都是在原有存储上扩展向量检索。优势是复用现有基础设施：业务数据、元数据、向量放一处，事务和权限体系照旧。缺点是向量能力是”附加功能”，极端规模下性能和功能不如专用库。

搜索与分析引擎。 Elasticsearch、OpenSearch、Typesense、Azure AI Search 本来就是做检索的，向量检索只是新技能。它们最强的点是混合搜索：关键词 BM25 检索和向量检索可以融合，中文等语言场景下”精确词匹配 + 语义匹配”互补效果很好。

选路线的核心问题：向量是主角还是配角。 应用就是做语义搜索，选专用库；应用有大量业务数据，顺便要向量能力，选扩展路线；内容检索复杂、要全文+向量混排，选搜索引擎。

36.3 云服务 vs 自建

同一条路线里，还要决定用云还是自己搭。

云托管（Pinecone、Azure、Bedrock、MongoDB Atlas、各家的云版）省运维，容量弹性伸缩，起步快。代价是按量付费，数据量大时成本高；数据出境和供应商锁定也是要考虑的。

自建（Docker 起 PGvector、Milvus、Qdrant 等）成本可控，数据在自己手里，可以深度调优。代价是部署、监控、扩容、备份全要自己管，团队得有对应的运维能力。

给个粗略的参考：起步阶段、数据量小，用云或本地 Docker 都行；数据量上来之后，自建的成本优势才显现，但前提是有人运维。

36.4 选型决策五问

选库不用纠结指标，按顺序问自己五个问题。

1. 现有技术栈是什么？ 有 PostgreSQL 就用 PGvector，有 Redis 就用 Redis，在 AWS 上就考虑 OpenSearch 或 S3。复用现有设施，学习成本和运维成本最低。这是最重要的一个问题。

2. 数据量多大？ 十万级以下，PGvector、Redis 都轻松应付。百万级往上，开始考虑 Milvus、Qdrant 这类专用库。千万级是专用库的主场。

3. 检索是核心功能吗？ 是，值得为检索单独上系统；只是辅助功能，优先扩展路线。

4. 需要混合搜索吗？ 需要关键词+向量混合、拼写容错，看 Elasticsearch、OpenSearch、Typesense、Azure AI Search。

5. 谁运维？ 没有专职运维，选云托管；有，自建省钱。

36.5 几个容易忽略的点

嵌入模型和向量库的维度必须一致。 换嵌入模型时，如果维度变了，旧向量库里的数据要重新生成。先定模型再定库，顺序别反。

metadata 过滤能力差异很大。 过滤表达式在 Spring AI 里是统一的，但底层实现能力不同：Redis 要求字段先注册，PGvector 翻译成 JSON 路径查询，is null 这类操作有的库还没实现。选型时把”要不要复杂过滤”问清楚。

特殊实现要留意。 Bedrock Knowledge Base 是只读的，文档摄取走服务内部流程；SimpleVectorStore 只能测试用；Cosmos DB 是外部模块，不进 Spring AI 主仓库。

36.6 小结

20 余种实现可以归成三条路线：专用向量库、传统库扩展、搜索引擎。选型先看现有技术栈，再看数据量和运维能力。云托管省心费钱，自建省钱费人。统一抽象让换库成本很低，起步别纠结，跑起来再优化。下一章把 RAG 的最后一环接上：检索增强问答与效果评估。