目录

零、说在前面

一、向量数据库是什么，为什么需要它

1.1 从"精确查找"到"语义检索"

1.2 向量数据库和向量库的区别（容易混淆）

二、主流开源向量数据库横向对比

2.1 核心能力全景对比

2.2 数据规模与扩展路线对比

2.3 索引算法简析（不想看可以跳过）

三、优缺点剖析

3.1 Chroma 的真实问题

3.2 Qdrant 的真实问题

3.3 Milvus 的真实问题

四、选型结论

4.1 针对我公司场景的判断矩阵

4.2 为什么"略显笨重"反而是优势

4.3 推荐的落地策略

五、说在最后

---

零、说在前面

        最近公司在做 AI 化改造，绕不开"RAG（检索增强生成）"这个词。RAG 的核心依赖之一就是向量数据库——把文字、文档、知识库内容转成高维向量存进去，查询时用语义相似度快速找到最相关的内容，再喂给大语言模型（LLM）生成回答。

        既然要用向量数据库，就免不了选型。市面上叫得上名字的产品有好几个：Milvus、Qdrant、Chroma、Weaviate、FAISS……网上的对比文章一搜一大把，但这些文章有个共同的毛病：每款产品都用不同的褒奖性语言介绍各自的优势，读完之后依然不知道该选哪个。

        本文的出发点，是基于我所在公司的真实业务场景和技术环境，给出一个有取舍的、负责任的选型结论，而不是面面俱到、谁都不得罪地"罗列优点"。

我们公司的实际情况如下：

• 操作系统： OpenEuler 22.03 虚拟机

• 数据规模：现阶段最大的 MySQL 数据表也只在百万级，属于中小型企业数据体量

• 使用场景：RAG 知识库、语义检索，当前以试水为主，不排除后续扩展到生产环境

• 核心诉求：现在用的和将来用的最好是同一款，避免试水完之后还要迁移换库

带着这些前提，我们来捋一捋主流向量数据库的异同、优缺点，以及最终应该选哪个。

一、向量数据库是什么，为什么需要它

        先说"向量数据库"是什么，它和关系型数据库（如 MySQL）有什么本质区别。

1.1 从"精确查找"到"语义检索"

        传统的 MySQL 查询是精确匹配的逻辑：WHERE name = '张三'，有就能找到，没有就找不到。这种方式在处理结构化数据时非常好用，但面对"帮我找一篇和《XX 合同》意思相近的文档"这类语义查询时，就无能为力了。

        向量数据库解决的正是这个问题。它的工作原理大致是：

1. 用 Embedding 模型（如 bge-m3、text-embedding-ada-002 等）把文本内容转化为一组高维浮点数向量（比如 1536 维）

2. 把这个向量存入向量数据库

3. 查询时，把用户问题也转化为向量

4. 数据库计算用户问题向量和库中所有向量的"距离"（即语义相似度），返回最近的 Top-K 条结果

5. 把这些结果拼入提示词，送给大模型生成回答

        这个过程就是 RAG 的核心链路。向量数据库是其中承上启下的"语义索引层"。

1.2 向量数据库和向量库的区别（容易混淆）

        有一个常见误区："向量数据库"和"向量库/索引库"不是同一个东西：

类型	代表产品	定位
向量索引库	FAISS、HNSWLib、Annoy	C++/Python 嵌入式库，只管索引和检索，不提供持久化、API、用户管理
向量数据库（服务化）	Milvus、Qdrant、Chroma	完整的数据库服务，有 CRUD、持久化、API、访问控制
传统数据库向量扩展	PostgreSQL + pgvector	在已有关系库中追加向量检索能力

        比如 FAISS 是 Meta 开源的"向量索引库"，性能极强，但它不是"数据库"——它更像是一个 Python 包，没有独立的服务进程，数据管理需要自己处理。因此向量索引库不是本文讨论的重点。

        而 pgvector 是在保留传统数据库的 SQL 能力和事务特性的基础上，在同一个系统内支持结构化 + 向量数据。其底层也会使用诸如 FAISS 等向量索引库。因此它们也不是本文讨论的重点。

二、主流开源向量数据库横向对比

        当前最常被讨论的三款开源向量数据库是 Milvus、Qdrant 和 Chroma。下面从多个维度做一个客观对比，重点呈现它们之间的差异而非各自的优势。

2.1 核心能力全景对比

对比维度	Milvus	Qdrant	Chroma
架构类型	分布式云原生	开源服务化（单进程/轻量集群）	嵌入式/轻量级
单索引数据规模上限	百亿级向量	千万级向量	百万级向量（实测舒适区）
持久化支持	是（MinIO/S3 等）	是（本地磁盘文件）	是（SQLite 文件）
分布式/集群支持	完整支持（Kubernetes）	部分支持（复制与分片）	不支持
REST/gRPC API	完整支持	完整支持	有限支持（主要通过 Python SDK）
混合检索（向量+标量过滤）	支持	支持（过滤能力强）	不支持
主要索引算法	IVF_FLAT、IVF_SQ8、HNSW、DiskANN 等	主要为 HNSW	HNSW
多语言 SDK	Python/Go/Java/Node.js 等	Python/Rust/Go/TypeScript 等	主要为 Python
部署复杂度	较高（依赖 Etcd、MinIO 等）	中等（单二进制即可）	低（pip 安装即可）
可视化管理工具	官方 Attu（Web GUI）	暂无官方 GUI	暂无官方 GUI
在 OpenEuler 上的资料	有专项测评和实践文档	通用 Linux 资料，OpenEuler 案例少	Python 环境适配，SQLite 版本有坑

2.2 数据规模与扩展路线对比

        直接上对比图：

阶段	Milvus	Qdrant	Chroma
原型/PoC（< 100 万向量）	用 Milvus Lite 或 Standalone，几行代码可跑起来	单二进制即可，同样轻便	pip 安装，最轻量
小型生产（百万～1000 万向量）	Milvus Standalone（单机 Docker 模式）	Qdrant 单节点部署即可支撑	开始触及舒适区边界，性能可能衰减
中型生产（> 1000 万向量）	Milvus Standalone 仍可支撑（官方称单机可达 1 亿向量）	需开启复制/分片	不建议继续使用
大型生产（亿级以上）	Milvus Distributed（K8s 集群）	勉强支撑	无法支撑

        关键信息： Milvus 的扩展路线是连续的——从 Milvus Lite → Standalone → Distributed，API 和集合结构不变，迁移时业务代码几乎不需要修改。

2.3 索引算法简析（可以跳过）

向量数据库里的"索引"决定了检索速度和精度的权衡。常见的几种：

• HNSW（Hierarchical Navigable Small World）：基于图结构，检索速度快、精度高，内存占用相对较大，是目前最常用的算法。Qdrant、Chroma 都以此为核心。

• IVF_FLAT（倒排文件索引）：先聚类、再检索，内存友好，适合数据量极大时的粗筛场景，但精度略低于 HNSW。

• DiskANN：Milvus 独家支持，数据存在磁盘而非内存，允许在内存有限的服务器上处理超大规模向量，是亿级数据场景的利器。

对于我们这样"百万级数据、RAG 场景"的使用需求，直接用 HNSW 即可，无需深入研究 IVF 和 DiskANN。

三、优缺点剖析

3.1 Chroma 的问题

        Chroma 最大的问题不是性能，而是它被设计成一个"库"而非"服务"，后期不适合生产环境：

• 默认的存储引擎是 SQLite，SQLite 不是为高并发场景设计的，当多个进程/线程同时读写时容易产生锁竞争

• 它没有官方的 Web 管理界面，运维全靠代码或命令行

• 在 OpenEuler 22.03 上，系统默认的 SQLite 版本往往低于 Chroma 要求的 3.35，需要额外处理（安装 pysqlite3-binary 替代），这是一个隐藏的坑

• 如果后期需要多语言（Java、Go）接入，Chroma 的 SDK 生态相对薄弱

        一句话：Chroma 适合教学和个人 PoC，不适合作为公司内部服务的长期基座。

3.2 Qdrant 的问题

        Qdrant 是三者中综合体验最均衡的，但它同样有几个限制：

• 分布式能力尚在演进中，生产集群方案的成熟度和社区案例数量不如 Milvus

• 在国内（尤其是华为/openEuler 生态）的专项适配资料明显少于 Milvus

• 没有官方的 GUI 工具，日常运维依赖 REST API 或第三方工具

• 数据规模上限官方标称为"千万级"，对于当前业务绰绰有余，但如果公司日后有大规模扩展需求，仍有一定风险

                一句话：Qdrant 是个不错的备选，但在"一条路走到底"这个诉求上，底气不如 Milvus 足。

3.3 Milvus 的问题

        没有谁是万金油，Milvus 也不例外：

• Standalone 模式存在单点故障风险：所有组件跑在同一个 Docker 容器中，服务器宕机即全部不可用，这是用单机换来便利性的代价

• 资源占用比 Qdrant 和 Chroma 高：Milvus Standalone 启动后空载内存占用大约在 2–4 GB，对于资源受限的虚拟机要提前预留

• 依赖链较长：Distributed 模式需要同时维护 Etcd（元数据）和 MinIO（对象存储），运维复杂度比 Qdrant 高

• 概念较多：Collection、Partition、Segment、Index 等概念比 Chroma 多，入门曲线稍陡

        但这些问题在"百万级数据、Standalone 单机"场景下，基本都不构成障碍。

四、选型结论

4.1 针对我公司场景的判断矩阵

把我的具体需求和三款产品做一次对号入座：

需求	Milvus	Qdrant	Chroma
现在试水，百万级数据	✅ 完全支撑	✅ 完全支撑	✅ 能用
未来可扩展到生产，同一套技术栈	✅ Standalone → Distributed，API 不变	⚠️ 有可能，但集群方案成熟度略低	❌ 不适合生产
OpenEuler 22.03 兼容性	✅ 有专项测评文档	⚠️ 通用 Linux，无专项	⚠️ SQLite 版本坑
避免换库（向后兼容）	✅ 官方明确支持三种部署模式平滑升级	⚠️ 升级路径存在，但不如 Milvus 完整	❌ 迁移必须换库
有 GUI 可视化管理界面	✅ 官方 Attu	❌ 无官方 GUI	❌ 无官方 GUI
多语言客户端支持	✅ Python/Java/Go/Node.js	✅ 多语言支持	⚠️ 主要是 Python

        结论：在我公司的场景下，首选 笨重的Milvus，Qdrant 可以作为备选但不作为第一选择，不推荐 Chroma 。

4.2 为什么"略显笨重"反而是优势

有人会觉得：现在才百万级数据，用 Milvus 是不是杀鸡用牛刀了？

我觉得，选型的目标不是让当下用着最省力，而是让技术栈具有连续性。

Milvus 的"略显笨重"体现在两个地方：

1. 启动比 Chroma 慢，空载内存多占 2–3 GB

2. 概念比 Chroma 多，上手曲线稍陡

但这两点带来的代价，换来的是：

• 现在在 OpenEuler 单机上跑的 Standalone，未来可以无缝扩展到 Distributed 集群，Collection 结构和业务代码不变

• 有 Attu 这个官方 GUI，日常运维、数据查看、索引管理都有图形界面，不用全靠命令行

• 在国内（包括华为/openEuler 生态）有更完整的落地实践和社区支持

• Python/Java/Go 全覆盖，公司后端无论用哪个语言框架，都能直接对接

所以，选 Milvus 不是因为它最流行，而是因为它最符合"一条路走到底"这个核心诉求。

4.3 推荐的落地策略

基于以上判断，建议按如下路线推进：

第一阶段（试水期）：

• 在 OpenEuler 22.03 上，通过 Docker 部署 Milvus Standalone

• 安装 Attu（Milvus 官方 GUI），作为可视化界面辅助

• 用 Python + LangChain 跑通一个最小 RAG Demo（文档录入 → 向量化 → 检索 → 大模型生成）

第二阶段（生产化）：

• 如果数据规模和并发要求还在 Standalone 范围内（百万级向量，QPS < 100），继续沿用，仅迁移数据目录到独立数据盘

• 如果规模超出，直接按官方路径升级至 Milvus Distributed（K8s 模式），业务层代码改动极小

这样既规避了"试水用 A、生产换 B"的迁移风险，也不会在早期为不必要的运维复杂度买单。

五、说在最后

        向量数据库的选型，本质上是在"灵活性"和"稳定性"之间做取舍。Chroma 是灵活性的极端，方便得几乎没有学习成本，但生命周期就到 PoC 为止；Milvus 是稳定性的极端，从百万到百亿的完整扩展路线，是专门为"认真做事"的场景设计的；Qdrant 则是两者之间的平衡点，但在国内生态和 OpenEuler 适配上略显薄弱。

        回到文章开头说的那个痛点：最怕的不是现在选错，而是选了一个"只能陪你走一半路"的产品，等到真正要上生产的时候才发现要推倒重来。

        基于这个逻辑，在"百万级数据、OpenEuler 22.03 环境、RAG 场景、追求向后兼容"的需求下，选 Milvus 妥妥哒。