生产环境向量检索数据库选型：Elasticsearch、Qdrant、Milvus 与 Chroma

生产环境向量检索数据库选型：Elasticsearch、Qdrant、Milvus 与 Chroma

Question Or Purpose

这篇笔记抛开具体 RAG 框架，回答以下问题：

1. Elasticsearch 是全文搜索引擎，为什么现在也能作为向量数据库？
2. Elasticsearch、Qdrant、Milvus、Chroma 的设计中心分别是什么？
3. 每种产品的主要代价是什么，而不只是"它擅长什么"？
4. 在生产环境中，应该按哪些指标和约束做选型？
5. 怎样设计公平的 POC，避免根据热度、宣传数字或单次 QPS 作决定？

本文主要讨论自建或托管形态下的检索引擎选择，不把某个产品的官方规模区间、单次 Benchmark 或默认参数当成普遍结论。

!info 版本基线

本页于 2026-08-24 根据四个产品的当前官方文档整理。向量索引、量化、混合检索、部署模式和商业功能变化很快；实际选型必须锁定具体版本、部署形态和许可后重新确认。

Short Answer

没有"生产环境统一最好的向量数据库"，只有与工作负载匹配的系统：

• Elasticsearch 是 Search-first：全文检索、分析器、字段查询、过滤、聚合和高亮是它的传统强项，后来补齐 dense vector、HNSW、量化和混合检索。适合关键词与语义都重要的企业搜索、商品搜索和知识检索。
• Qdrant 是 Vector-first：向量、JSON Payload、过滤、多向量、Dense + Sparse 和多阶段查询结合紧密。适合自研语义搜索、推荐和 RAG 服务，希望使用专用向量引擎但不想一开始维护大型多组件平台的团队。
• Milvus 是 Distributed-vector-first：提供多种向量索引、计算存储分离和可独立扩展的分布式组件。适合向量是核心数据面、规模很大、负载差异明显，并且团队具备 Kubernetes 与分布式系统运维能力的场景。
• Chroma 是 Developer-first：从嵌入式 Local、单节点到分布式提供一致 API，适合快速实验、应用内嵌和中小规模服务。它已经不只是 Demo 工具，但生产选型仍应按所选部署模式验证高可用、备份、升级和容量。

最重要的生产原则是：

先把必须满足的查询语义、召回质量、延迟、数据新鲜度、隔离和恢复目标写成硬门槛，再对通过门槛的产品比较总成本；不要从"哪个数据库最热门"开始。

Evidence

1. Elasticsearch 向量能力的关键时间线

• Elasticsearch 7.6 的 dense_vector 字段已经达到 GA，可稳定存储向量，并通过精确计算完成相似度搜索。
• Elasticsearch 8.0 在 2022 年引入基于 HNSW 的高效近似最近邻检索；当时新的 kNN Endpoint 仍是 Technical Preview，所以 8.0 是能力分水岭，不等于成熟度在某一天突然完成。
• 后续 8.x 持续补齐过滤、Search API 集成、混合检索、量化、Oversampling 和 Rescoring 等能力。
• 当前官方文档列出的向量索引已包括 HNSW、量化 HNSW、Flat 和 Disk-oriented 方案；具体默认值随版本变化，不能把 latest 文档直接套到旧集群。

来源：Elasticsearch 8.0 ANN 介绍、dense_vector 官方文档。

2. 三个向量原生产品已经发生的变化

• Qdrant 已支持 Dense、Sparse、多个 Named Vectors、RRF/DBSF 融合以及多阶段查询，不再只是单路 Dense ANN。
• Milvus 已支持 Dense、Sparse、BM25、Hybrid Search 和多种 CPU、GPU、内存及磁盘索引。
• Chroma 当前提供 Local、Single-Node、Distributed 三种模式；单节点官方典型建议是少于约一千万条记录和少量 Collections，分布式模式则使用独立服务、对象存储、SQL Catalog 与本地 SSD Cache。

这些是产品能力事实，不代表它们在任何真实数据上都具有相同召回、延迟或运维成熟度。

Reasoning Or Structure

1. 先纠正分类：支持向量检索，不等于产品只有一种身份

"向量数据库"更像能力与产品定位，而不是严格的数据库学分类。

一个系统只要能够可靠地完成以下工作，就可以承担 Vector Store 或 Vector Search Engine 的角色：

1. 持久保存向量及其 ID、Payload 或文档；
2. 建立 Exact 或 ANN 索引；
3. 按 Cosine、Dot Product、Euclidean 等相似度检索 Top-K；
4. 结合元数据过滤；
5. 完成更新、删除、复制、备份和恢复。

因此：

• Elasticsearch 是搜索引擎出身，但可以承担生产向量检索；
• PostgreSQL 加 pgvector 仍是关系型数据库，但也能承担向量检索；
• Qdrant、Milvus、Chroma 的数据模型和工程重点从一开始更偏向向量工作负载。

真正需要比较的是"设计中心"与自己的查询，而不是争论谁有资格被叫作向量数据库。

1.1 检索索引通常不是业务事实库

向量库或搜索引擎通常应被视为可重建的 Retrieval Index，而不是订单、权限、支付或审批的唯一事实来源。

一个更稳妥的边界是：

关系型数据库
  └─ 用户、租户、权限、任务、业务状态、索引版本

对象存储
  └─ PDF、图片、音频、原始文档和解析产物

搜索或向量引擎
  └─ Chunk、Embedding、可过滤 Payload、全文或稀疏索引

这样才能在更换 Embedding 模型、调整 Chunk、重建索引或迁移数据库时保留原始事实。

2. 第一问不是"选哪个"，而是"要不要增加一个独立数据库"

以下情况下，现有 PostgreSQL + pgvector、应用内索引或托管搜索服务可能已经足够：

• 向量数量不大，并发低；
• 结构化过滤和事务比向量吞吐更重要；
• 团队很小，不希望多维护一个有状态集群；
• 数据与权限已经全部位于 PostgreSQL；
• POC 目标只是验证 Chunk、Embedding 和检索质量。

考虑引入独立向量或搜索引擎的信号包括：

• 向量工作集、索引或并发已超出当前数据库的成本或延迟目标；
• 需要独立扩容检索，而不希望影响交易数据库；
• 需要复杂全文搜索、Hybrid Retrieval、Multi-vector 或专用 ANN 调优；
• 多租户过滤、索引重建、批量摄取成为主要负载；
• 已有明确的高可用、容量和专职运维要求。

!warning 常见反模式

"数据以后可能很多"不是立即引入大型分布式向量集群的充分理由。应先给出增长速度、容量拐点和迁移触发条件。

3. 生产选型必须先定义七类工作负载

3.1 查询语义

需要明确：

• 只做 Dense Semantic Search，还是还要关键词搜索？
• 关键词是简单 Contains，还是需要 BM25、Phrase、Analyzer、同义词、模糊匹配和字段权重？
• 是否需要 Dense + Sparse + Rerank？
• 是否需要 ColBERT 等 Multi-vector 或 Late Interaction？
• Top-K 是 10、100，还是数千？
• 是否必须支持 Exact Search 作为小集合或评测基线？

3.2 过滤特征

过滤经常比"向量总量"更能决定性能：

• 每次查询是否都按 tenant_id、ACL、department、language 或 time_range 过滤？
• 过滤后保留 50%、10%、1% 还是万分之一的数据？
• 字段基数多大，是否存在大量小租户或少量超大租户？
• 过滤字段是否建立专用索引？

ANN 是近似搜索。过滤发生在候选生成前、图遍历中还是候选生成后，会直接影响 Recall、Latency 和 CPU。

3.3 数据规模与形态

至少记录：

• 向量数量 N；
• 维度 d；
• float32、float16、int8、binary 等数据类型；
• 每条 Payload、原文和元数据的平均及 P99 大小；
• 每个对象包含一个还是多个向量；
• 数据增长速度与保留期限；
• 删除、更新和重新 Embedding 的比例。

3.4 读写模型与新鲜度

• Read-heavy、Write-heavy 还是混合负载？
• 是每日批量导入，还是持续流式写入？
• 新数据多久必须可搜索：立即、数秒、数分钟？
• 删除请求多久必须在所有副本和缓存中消失？
• 查询与索引构建是否会争抢 CPU、RAM 和 I/O？

3.5 SLO 与检索质量

生产目标至少应包含：

• Recall@K、Precision@K、MRR、nDCG 或业务命中率；
• p50、p95、p99 Latency；
• 峰值 QPS 与并发数；
• 写入吞吐与 Write-to-search Delay；
• Availability、RPO、RTO；
• 节点、磁盘或可用区故障时允许怎样降级。

3.6 多租户、安全与合规

• 租户通过 Collection/Index、Shard，还是 Payload/Document Filter 隔离？
• 是否会因漏传过滤条件发生跨租户数据泄漏？
• 是否需要 TLS、RBAC、Audit、Field-level Security、Private Network？
• 备份中是否包含敏感 Payload 和原始文本？
• 数据删除和保留策略能否满足合规要求？

3.7 团队与部署约束

• 团队是否已经维护 Elasticsearch、Kubernetes、对象存储或 etcd？
• 选择 Self-hosted 还是 Managed Service？
• 是否允许 JVM？是否只能运行单机 Docker？
• 是否支持目标 CPU 架构和文件系统？
• 许可、商业功能和支持 SLA 是否可接受？

4. 容量估算：不要只数"多少条文档"

4.1 原始向量大小

未压缩向量的基础大小为：

raw_vector_bytes = vector_count × dimensions × bytes_per_dimension

例如一千万条、768 维、float32 向量：

10,000,000 × 768 × 4
= 30.72 GB
≈ 28.6 GiB

这只是原始向量，不包括：

• HNSW Graph、IVF、PQ 或 Sparse Index；
• Quantized Copy 与用于 Rescore 的原始向量；
• ID 映射；
• Payload、原文、倒排索引和 Doc Values；
• WAL、Segment、Merge/Compaction 临时空间；
• Replica；
• Snapshot；
• OS Page Cache 与进程自身开销。

因此"原始向量只有 30 GB"不代表一台 32 GB RAM 机器就能稳定运行生产服务。

4.2 Replica 会成倍增加集群总资源

Replica 不一定让单节点放两份数据，因为副本可以分散在其他节点；但整个集群需要保存多份数据和索引，也要承担复制、恢复和网络成本。

容量规划应至少按下式思考：

cluster_footprint
≈ per_replica_data_and_index × replication_factor
  + WAL_and_temporary_space
  + safety_headroom

4.3 HNSW 的基本取舍

HNSW 常见于 Elasticsearch 和 Qdrant，也是 Milvus 可选索引之一。

• 增大 Graph Connectivity 或构建参数，通常提高 Recall，但增加建索引时间和空间；
• 增大查询候选数或 ef_search，通常提高 Recall，但增加 CPU 和 Latency；
• 向量量化能减少内存和带宽，但会损失部分精度；
• Oversampling + Rescore 可以追回部分精度，但又增加计算和原始向量访问；
• 工作集无法进入 RAM/Page Cache 时，磁盘类型与 IOPS 会显著影响尾延迟。

ANN 调优永远是 Recall、Latency、Build Time、Memory 和 Cost 的联合优化，不是只把一个参数调大。

5. Elasticsearch：Search-first 的混合检索平台

5.1 设计中心

Elasticsearch 的核心仍然是基于 Lucene 的分布式文档搜索：JSON Document、倒排索引、Analyzer、Query DSL、Filter、Aggregation、Highlight、Shard 和 Replica。

向量能力加入后，一条文档可以同时拥有：

• 可做 BM25 的 Text Fields；
• 精确匹配用的 Keyword Fields；
• 数值、时间、地理和布尔字段；
• Dense 或 Sparse Vector；
• 排序、聚合和业务特征字段。

当前官方推荐可用 RRF 等方式在一个搜索请求中合并全文与向量排名。Hybrid Search 官方文档

5.2 主要优势

1. 复杂词法检索能力完整：Analyzer、分词、多字段、Phrase、Fuzzy、Synonym、BM25、Highlight 和 Query DSL 经过长期搜索业务验证。
2. Hybrid Search 自然：同一文档、同一权限过滤和同一查询接口中组合 Lexical、Dense、Sparse、RRF 或 Linear Fusion。
3. 结构化搜索能力强：过滤、聚合、排序、时间、地理和多字段搜索不需要另建一套检索系统。
4. 分布式运维生态成熟：Shard、Replica、Snapshot、Rolling Upgrade、监控和托管服务生态完整。
5. 已有 Elasticsearch 团队迁移成本低：能复用已有知识、网络、安全、告警和容量管理体系。

5.3 主要代价

资源代价

• 同时保存 Source、倒排索引、Doc Values、Vector 和 ANN Index，磁盘占用通常高于只保存向量及精简 Payload 的系统。
• HNSW 构建需要 CPU，索引期间会与在线查询或写入争抢资源。
• 高效查询依赖合理的 RAM 与 Page Cache；只按 JVM Heap 估算容量会漏掉大量实际工作集。
• Replica、Shard 和 Segment Merge 会进一步增加存储、网络和后台 I/O。

运维代价

• 需要理解 JVM Heap、Page Cache、Shard 大小与数量、Cluster State、Mapping、Refresh、Merge 和 Reindex。
• Shard 过多会增加 Cluster State 与小分片开销；Shard 过少又可能限制扩容和并行度。
• Mapping 或向量维度变化通常需要新建索引并 Reindex，而不是原地轻松修改。
• 自建多可用区集群需要正确配置副本和 Shard Allocation Awareness；官方生产参考建议至少两个可用区，理想情况下三个可用区。Elastic HA 参考架构

检索代价

• Vector-only 工作负载下，它未必在每单位 RAM、磁盘或成本的 ANN QPS 上优于专用向量引擎，必须实测。
• BM25 分数与 Vector Similarity 的分布不同，直接加权容易失衡；RRF 更稳健，线性融合则需要评测集和归一化。
• 增大 num_candidates、Oversampling 或 Rerank 能改善 Recall，但会增加延迟与计算成本。

组织与商业代价

• Elasticsearch 版本、发行方式、插件和高级功能对应的许可及订阅边界需要由团队和法务确认。
• 若团队完全没有 Elasticsearch 经验，只为少量向量引入它，学习和运维成本可能高于收益。

5.4 适合使用

• 企业文档、法规、客服、商品或站内搜索；
• 用户会输入 SKU、错误码、人名、型号等必须精确命中的词；
• 需要 Phrase、Analyzer、Synonym、Highlight、Aggregation；
• 搜索条件包含复杂权限、时间、分类、地域和业务排序；
• 已经有 Elasticsearch 平台和运维团队；
• 希望在一套 Search Engine 中完成 Lexical + Vector + Filter + Rerank Candidate Generation。

5.5 不应默认选择

• 业务只是纯 Dense ANN，没有复杂文本或聚合需求；
• 数据规模很小，现有 PostgreSQL/pgvector 已满足 SLO；
• 硬件预算非常紧，团队也没有 JVM/Elasticsearch 经验；
• 目标是超大规模纯向量平台，并且已有更适合的向量原生基础设施。

6. Qdrant：Vector-first 与过滤结合紧密

6.1 设计中心

Qdrant 的基本对象是 Point：ID、一个或多个向量，以及 JSON Payload。它围绕 HNSW、Payload Index、Dense/Sparse/Multi-vector、Quantization、Hybrid Query 和分布式 Shard 设计。

Qdrant Query API 可以通过 Prefetch 组合多个检索分支，再使用 RRF、DBSF 或后续 Formula/Rescore 完成融合和多阶段查询。Qdrant Hybrid Queries

6.2 主要优势

1. 向量与过滤是一等能力：Payload 可保存结构化字段，并为常用过滤字段建立 Payload Index。
2. Dense、Sparse 和 Multi-vector 统一：适合 Dense Semantic、BM25/Sparse、ColBERT 或多模态表示并存。
3. 多阶段查询表达直接：可先低成本召回，再用更昂贵的向量或公式重排。
4. 内存与磁盘放置可调：当前文档允许按结构选择 Pinned、Cached、Cold 等 Memory Tier，并支持 Quantization。
5. 多租户方案明确：可用 Tenant Payload、User-defined Sharding 或混合方式组织租户，而不是默认每个租户一个 Collection。

6.3 主要代价

资源代价

• Payload Index 不是免费的：它会增加磁盘和常驻 RAM。只应索引实际参与过滤的字段。
• Cached/Pinned 能降低查询延迟，但工作集越热，RAM 成本越高；Cold/On-disk 能节省 RAM，但增加 Page Fault、SSD I/O 和尾延迟。
• Quantization 节省内存，却可能降低 Recall；若用 Oversampling 和原向量 Rescore，又会增加 I/O 与计算。
• Dense、Sparse、Late-interaction 各保存一套向量时，容量必须分别计算，不能只算主 Dense Vector。

Qdrant 官方 Capacity Planning 明确要求分别估算向量、HNSW、Payload、Payload Index、ID Tracker、Replica 和 Headroom。Qdrant Capacity Planning

运维代价

• 分布式模式仍需规划 Shard、Replica、Consensus、Load Balancer、故障恢复和 Rebalance，不是启动多个容器就自动获得完整 HA。
• Shard 转移方式不同，是否携带 HNSW/Quantization Index 也不同；某些迁移路径需要目标节点重新优化索引，成本可能很高。Qdrant Distributed Deployment
• Self-hosted On-disk 检索依赖低延迟 SSD/NVMe。当前官方安装文档要求具备 POSIX 文件系统语义的块存储，不支持把持久目录直接放在 NFS 等网络文件系统上，也不能把 S3 对象存储直接当成本地持久卷。
• 备份、Snapshot、滚动升级和节点替换必须实际演练，不能只验证正常查询。

一致性代价

• 默认配置倾向搜索可用性与吞吐；并发修改同一 Point 时，需要根据业务显式设置 Write Consistency、Read Consistency 或 Write Ordering。
• 提高一致性通常需要更多副本响应或额外 Fan-out，会增加写入或读取延迟。Qdrant Consistency Guarantees

搜索边界

• Qdrant 官方明确把自身定位为 Vector Search Engine，全文能力围绕向量用例展开；若需要 Elasticsearch 级 Analyzer、Phrase、复杂相关性调试、Aggregation 和日志分析，应逐项验证，不能因"支持 Full-text"就认为能力等价。
• 多租户若完全依赖应用传入 tenant_id Filter，漏传过滤条件可能造成越权；服务端封装、测试和权限边界仍由应用负责。

6.4 适合使用

• 自研 RAG、语义搜索、推荐、相似商品或内容检索；
• Vector + Payload Filter 是主查询；
• 需要 Dense + Sparse、Multi-vector 或多阶段重排；
• 希望专用向量引擎支持单机到多节点扩展；
• 团队愿意维护分片和副本，但不需要 Milvus Distributed 那样的多角色计算平台。

推断：根据两者公开架构，Qdrant 的分布式组件形态通常比 Milvus Distributed 紧凑，因此中等规模团队更容易建立完整心智模型；这不代表 Qdrant 在所有规模上更便宜或更快。

6.5 不应默认选择

• 复杂全文搜索和搜索分析是产品核心；
• 需要大量传统 Aggregation、Log Analytics 或 Elasticsearch Query DSL 生态；
• 只需要少量向量，现有关系型数据库已经足够；
• 不能提供适合 On-disk Search 的本地块存储。

7. Milvus：面向大规模的分布式向量平台

7.1 设计中心

Milvus 提供三种部署模式：

• Milvus Lite：应用内 Python Library，适合 Notebook、Edge 和原型；
• Milvus Standalone：单机 Server，组件打包到单个部署中；
• Milvus Distributed：基于 Kubernetes 的分布式形态，组件可独立扩展。

官方将 Lite、Standalone、Distributed 分别对应从小规模到数十亿级的不同阶段，但这些数字是产品容量指导，不是对任意维度、Payload、过滤和 SLO 的保证。Milvus Deployment Options

7.2 主要优势

1. 扩展边界高：Distributed 将 Query、Ingestion、Streaming、Coordination 和 Storage 分离，适合读写负载差异明显的大规模系统。
2. 索引选择丰富：支持 HNSW、IVF 系列、PQ/SQ、DiskANN、SCANN、GPU Index 和 Exact Flat 等多类方案。
3. 向量类型丰富：Dense、Sparse、Binary、Multi-vector 和多模态场景都能建模。
4. Hybrid 能力已增强：Milvus 支持 Sparse Index、内置 BM25 Function 和 Hybrid Search，不再只是 Dense ANN。
5. 一致性可选：Strong、Bounded Staleness、Session、Eventual 可按业务在 Freshness、Latency 与 Availability 之间取舍。
6. 计算与存储可分别扩展：大规模场景可以针对 Query-heavy 或 Ingestion-heavy 分配不同资源。

7.3 主要代价

架构与运维代价

Milvus Distributed 当前包含 Coordinator、Proxy、Streaming Node、Query Node、Data Node，并依赖 Metadata Store、Object Storage 和 WAL Storage。每个组件可以独立扩容，但也意味着：

• 部署、升级、监控、告警和容量规划对象更多；
• Kubernetes、对象存储、元数据服务和网络都可能成为故障域；
• 需要理解各角色积压、Segment、Compaction、Load 和 Index Build；
• 小规模业务也要承担较高的集群固定成本。

来源：Milvus Main Components。

迁移代价

• Lite 数据可通过工具迁往 Standalone 或 Distributed；
• 当前官方组件文档指出 Standalone 不能在线升级为 Cluster，所以从单机跨越到分布式时需要提前设计导出、导入、双写或停机窗口；
• Embedding、Schema 或 Index Strategy 变化也可能触发大规模重建。

索引选择代价

更多索引意味着更大调优空间，也意味着更复杂的决策：

• HNSW：低 Top-K、高 Recall 常见，但 Graph 占用额外空间；
• IVF：在部分 Large-K 或 Filter Pattern 下可能更合适，但需要训练和参数选择；
• PQ/SQ：节省空间，牺牲精度；
• DiskANN：突破 RAM 容量，换来 SSD/IOPS 约束；
• GPU Index：提高特定负载吞吐，但增加硬件、驱动与调度复杂度；
• Flat：精确但计算量随候选集合增长。

Milvus 官方索引指南也强调，Index Type 必须围绕 Build Time、QPS、Recall、Top-K、Filter Ratio、RAM 和 Disk 联合选择，而不是固定使用 HNSW。Milvus Index Explained

一致性与新鲜度代价

Milvus 默认使用 Bounded Staleness。Strong Consistency 可以保证看到更新的数据，但 Query Node 可能需要等待数据时间戳推进，从而增加 Latency。对"写入后立刻搜索"或删除传播敏感的业务必须显式选择和测试一致性级别。Milvus Consistency

成本代价

• 分布式组件、对象存储、WAL、Metadata、Kubernetes 节点和跨组件网络共同构成 TCO；
• Query Replica 提高可用性或吞吐，同时增加内存和计算；
• 低负载集群可能因固定组件长期空闲而产生较高单位成本；
• 托管 Zilliz Cloud 可减少运维，但需比较服务费用、网络、数据迁移和 Vendor Lock-in。

7.4 适合使用

• 数千万到十亿级甚至更高的向量工作负载，且已经通过容量测试证明需要分布式扩展；
• 图片、视频、音频、商品或推荐等 Vector-first、多模态系统；
• 查询和摄取需要独立扩容；
• 需要在 HNSW、IVF、PQ、DiskANN 或 GPU Index 之间按负载选择；
• 团队具备 Kubernetes、对象存储、分布式服务和容量规划能力。

7.5 不应默认选择

• 只是因为"未来可能达到亿级"；
• 当前只有一个小型知识库和有限并发；
• 没有专人维护 Kubernetes 与依赖服务；
• 需要强全文搜索，却不愿另外设计 Lexical Retrieval；
• 无法接受 Standalone 到 Distributed 的迁移工程。

8. Chroma：从本地开发到分布式的一致 API

8.1 设计中心

Chroma 强调开发者体验：应用可以在本地嵌入式模式快速开始，再使用 Single-Node Server 或 Distributed/Chroma Cloud。

当前官方架构将部署分为：

• Local：嵌入应用，适合原型与实验；
• Single-Node：单服务器，官方典型建议为少量 Collections、少于约一千万 Records；
• Distributed：Gateway、Log、Query Executor、Compactor、System DB 等服务独立部署，并使用对象存储、SQL Catalog 与本地 SSD Cache。

来源：Chroma Architecture Overview、Chroma Distributed Architecture。

8.2 主要优势

1. 开始成本低：Local 模式适合 Notebook、个人项目和应用内实验。
2. API 一致：从 Local 到 Server/Distributed 保持相近的数据模型和调用方式，减少早期代码切换成本。
3. Vector、Document、Metadata 一体：Collection 可以保存 Embedding、文本和 Metadata，并执行向量查询和过滤。
4. 部署梯度清楚：可以先 Local，再 Single-Node，随后评估 Managed Distributed。
5. 适合快速验证检索链路：在模型、Chunk、Embedding 和 Rerank 尚未确定时，不必先维护大型集群。

8.3 主要代价

Local 与 Single-Node 的可靠性代价

• Local 适合开发，并不自动提供跨机器 HA；
• Single-Node 本质上仍有单机容量和故障边界；
• 进入生产前必须自行验证备份、Restore、并发写入、进程或机器故障、磁盘耗尽和版本升级。

推断：若业务强制要求跨可用区、自动故障转移和严格 RTO，不能因为 API 简单就默认 Single-Node 足够。

Distributed 的复杂度代价

Chroma Distributed 不是"把本地 Chroma 多开几个副本"。它引入 Gateway、Log、Query Executor、Compactor、System Database、Cloud Object Storage 和 SSD Cache，因此：

• 运维对象和网络路径明显增加；
• 需要监控 Compaction、Cache、Object Storage、SQL Catalog 和服务间通信；
• 自建与 Chroma Cloud 的成本模型不同，必须分别评估。

全文搜索边界

Chroma 当前 Full-text Search 文档提供 c o n t a i n s < / c o d e > 、 < c o d e > contains、 contains、not_contains、Regex 和 Metadata Filter；其中 Contains 是大小写敏感的文档过滤。它不能仅凭"支持 Full-text"就等同于 Elasticsearch 的 BM25、Analyzer、Phrase、Synonym、Highlight 和复杂相关性排名。Chroma Full Text Search

规模与成熟度验证成本

• 官方给出的记录数量是典型部署指导，不是性能保证；
• 生产前仍需用真实维度、Payload、并发、更新率和过滤条件测试；
• 从 Local/Single-Node 到 Distributed 时，需要验证数据迁移、行为差异、备份和回滚流程，而不应只验证 Client API 能否连接。

8.4 适合使用

• 学习 Embedding、RAG 和 Semantic Search；
• Notebook、桌面工具、Edge 或应用内嵌检索；
• 小团队快速验证 Product-Market Fit；
• 数据和并发在单机能力内，并能接受单机恢复策略；
• 希望使用 Chroma Cloud 的团队，并已验证服务地区、SLA、安全和成本。

8.5 不应默认选择

• 产品核心是复杂 BM25 和企业全文搜索；
• 已明确需要严格的多可用区自建 HA，却尚未评估 Distributed；
• 超大规模、极高并发或高写入负载只有宣传数字，没有自己的 POC；
• 团队把 Local 开发体验误当成生产运维已经解决。

9. 四种产品的对比矩阵

下表描述"产品中心与典型适配度"，不是性能排名。任何"强、中、需验证"都必须被具体版本和 POC 覆盖。

维度	Elasticsearch	Qdrant	Milvus	Chroma
产品中心	全文与通用搜索优先	向量与 Payload Filter 优先	大规模分布式向量平台	开发体验与渐进部署优先
Dense ANN	强	强	强，索引选择最多	支持，按模式验证规模
复杂 BM25/Analyzer	最完整	有 Sparse/Full-text，但边界较窄	已支持 BM25/Sparse，搜索生态仍偏向量	Contains/Regex Filter，不等同复杂 BM25
Hybrid Retrieval	原生全文 + Dense/Sparse + RRF/Linear	Dense + Sparse + RRF/DBSF + Multi-stage	Dense + Sparse/BM25 + Hybrid	Vector + 文档/元数据过滤；复杂融合需核对版本或应用实现
Metadata Filter	Query DSL 很强	Payload Index 是核心能力	Scalar/JSON/Partition Filter	支持 Metadata Filter
Multi-vector/多模态	可实现，需按字段和查询设计	Named/Multi-vector 强	多向量、二进制、GPU 等选择丰富	适合常规 Collection 模型，复杂需求需实测
单机启动成本	中等偏高	低到中	Lite 低、Standalone 中	Local 最低、Single-Node 低
分布式运维固定成本	中到高	中	最高	Distributed 中到高
超大规模水平扩展	强，但需正确分片	强	设计重点	Distributed 支持，需按实际版本验证
传统搜索与分析生态	最强	有限	有限	有限
典型首选场景	企业搜索、Hybrid Search	过滤型语义检索、自研 RAG/推荐	超大规模、多模态、Vector-first 平台	原型、内嵌、小中规模与渐进开发

10. 按典型生产场景选择

场景 A：企业知识库、客服、法规和商品搜索

特征：

• 错误码、SKU、人名、型号和法条必须准确命中；
• 同时希望找到语义相近表达；
• 权限、部门、时间和分类过滤复杂；
• 需要 Highlight、Aggregation 和搜索调试。

优先评估：Elasticsearch。

原因：这本质是全文搜索与语义搜索的混合问题，不是纯 ANN 问题。

场景 B：自研 RAG 或语义搜索 SaaS

特征：

• Dense + Sparse + Rerank；
• 大量 Payload Filter；
• 需要多租户、Named Vector 或 Multi-stage；
• 不需要 Elasticsearch 级日志分析和复杂聚合。

优先评估：Qdrant，并与现有 PostgreSQL/pgvector 做成本基线比较。

场景 C：超大规模图片、视频、音频或推荐平台

特征：

• 向量是主要查询入口；
• 数据量和并发已被实际容量测试证明超出单机；
• 查询与摄取需要独立扩容；
• 需要多种 ANN、DiskANN、压缩或 GPU。

优先评估：Milvus Distributed。

前提：具备 Kubernetes、对象存储、依赖服务和专职运维能力。

场景 D：原型、个人知识库、Notebook、桌面应用

特征：

• 优先验证产品和检索效果；
• 数据少、并发低；
• 希望最少配置运行；
• 暂无复杂 HA 目标。

优先评估：Chroma Local 或 Milvus Lite；若数据本来就在 PostgreSQL，也可直接使用 pgvector。

场景 E：中小规模生产，但团队没有专职数据库运维

不要直接根据产品名字决定。优先级通常是：

1. 已经在用并且满足 SLO 的数据库扩展；
2. 满足需求的 Managed Service；
3. 组件较少的 Self-hosted Single-Node + 完整备份恢复；
4. 只有在容量、HA 或隔离确实需要时才升级为分布式。

推断：对小团队而言，工程师维护时间往往比单台服务器价格更贵，因此 TCO 不能只比较云账单。

场景 F：团队已有成熟 Elasticsearch 平台

若现有 Elasticsearch 的向量召回、p99 和成本能达标，继续使用通常比新引入一个向量数据库更合理。新数据库意味着：

• 新的部署、监控、权限、备份和升级体系；
• 数据双写、重建和迁移；
• 两套查询与故障排查心智模型；
• 更多跨系统一致性问题。

只有实测证明专用向量引擎带来足够大的质量、性能或成本收益时，新增系统才有合理性。

11. 生产 POC：怎样做公平比较

11.1 先设置 Hard Gates

任何一项不满足就淘汰，而不是靠其他加分弥补：

• 必须支持目标部署区域和 CPU 架构；
• 必须支持租户隔离、TLS、认证和审计要求；
• 必须达到最低 Recall@K 和 p99；
• 必须满足 Write-to-search Delay 与删除传播要求；
• 必须在节点故障后达到 RPO/RTO；
• 必须具备可验证的 Backup/Restore；
• Client SDK、License 和升级路径必须可接受。

11.2 使用同一份真实数据

四个候选系统必须使用：

• 相同文档与 Chunk；
• 相同 Embedding Model、版本、维度和归一化方式；
• 相同 Payload 与过滤字段；
• 相同 Query Set；
• 相同 Ground Truth 或人工相关性标签；
• 相同 Reranker 和下游生成模型。

否则测到的差异可能来自 Embedding 或 Chunk，而不是数据库。

11.3 至少覆盖六类测试

测试	必测内容
纯向量	Top-K、Recall、p50/p95/p99、QPS
Hybrid	Lexical + Dense/Sparse 的 nDCG/MRR、融合参数
Filter	高/中/低 Selectivity、不同租户大小、ACL
混合读写	在线查询同时批量写入、更新和删除
冷热状态	Cold Start、Warm Cache、内存压力、磁盘 I/O
故障恢复	节点故障、Replica 接管、Snapshot Restore、Reindex

11.4 同时记录质量、性能和成本

不能只记录 QPS：

• 质量：Recall@K、Precision@K、MRR、nDCG、答案命中率；
• 性能：p50/p95/p99、QPS、Timeout、Error Rate；
• 摄取：Rows/s、Index Build Time、Compaction/Merge 时间；
• 新鲜度：写入或删除后多久对查询生效；
• 资源：CPU、RAM、Page Cache、Disk、IOPS、Network；
• 恢复：重新加载、Rebalance、Restore、Reindex 时间；
• 成本：计算、存储、流量、许可、托管费用和人力。

11.5 公平调参

• 先测默认配置了解易用性；
• 再给每个系统合理的专家调优机会；
• 在相同 Recall 水平下比较 Latency/QPS，而不是一个系统 Recall 70%、另一个 95% 仍直接比较 QPS；
• 在最终计划使用的 Replica、Shard 和安全配置下复测；
• 同时测 Warm 与 Cold，不要只展示缓存已热的最佳数字；
• 保存完整配置、版本、数据集 Hash 和执行脚本，确保可重复。

12. 一个可复用的决策评分表

Hard Gates 通过后，可以按业务调整权重。以下只是示例：

维度	示例权重	评分依据
检索质量	30%	Recall、nDCG、业务命中、Hybrid/Rerank 效果
性能与新鲜度	20%	p99、峰值 QPS、写入可见延迟
高可用与恢复	15%	Replica、Failover、RPO/RTO、Restore Drill
三年 TCO	15%	计算、RAM、SSD、对象存储、流量、许可、人力
运维复杂度	10%	组件数量、升级、监控、扩缩容、故障定位
安全与生态	10%	Auth、TLS、Audit、SDK、社区、供应商支持

计算分数前应先保存每项原始数据，避免一个总分掩盖关键差异。

13. 常见错误选型方式

错误 1：只按向量总数选择

同样是一千万向量，384 维 int8 与 3072 维 float32 的容量差别巨大；一个 Vector 与三个 Named Vectors 也完全不同。

错误 2：只跑随机向量 Benchmark

随机向量无法代表真实语义分布、租户倾斜、过滤和更新模式，也不能评价 Hybrid Search 的相关性。

错误 3：只看平均延迟

生产体验通常受 p99、Timeout、Compaction、Merge、GC、Page Fault 和 Failover 影响。

错误 4：只看检索速度，不固定 Recall

ANN 可以通过减少搜索候选得到很高 QPS，但可能漏掉关键文档。不同系统必须在相近 Recall 下比较。

错误 5：认为支持 Full-text 就等价

Contains、Sparse Vector、BM25、Analyzer、Phrase 和 Fuzzy Search 是不同层级的能力，不能都写成一个勾选项。

错误 6：认为 Managed Service 一定贵或一定便宜

托管服务增加账单，却可能减少值班、升级和故障恢复人力；Self-hosted 节省服务费，却需要自己承担平台工程。应比较三年 TCO。

错误 7：忽略删除和重建

Embedding 模型升级、Chunk 策略变化、权限修复和合规删除都可能要求重建索引。只测试首次导入是不完整的。

错误 8：把生产数据只存向量库

如果没有原始数据、版本信息和可重复的 Ingestion Pipeline，索引损坏或模型升级会变成不可恢复事件。

14. 上线前工程清单

数据与索引

• 原始数据和业务事实有独立 Source of Truth
• Chunk ID、Document ID、Tenant ID 和 Embedding Version 可追踪
• Ingestion 幂等，重复执行不会生成重复记录
• 删除会同步到所有检索表示和副本
• 具备 Blue/Green Index 或 Collection 切换方案
• 能在不中断旧索引的情况下重建新 Embedding

性能与容量

• 按向量、索引、Payload、WAL、临时空间和 Replica 完成估算
• 保留容量与磁盘安全水位
• 测过 Mixed Read/Write、Cold Cache 与高过滤场景
• 监控 p95/p99、Timeout、Recall Sample 和 Freshness
• 记录 Index Build、Merge/Compaction 和 Rebalance 指标

高可用与恢复

• Replica 分布在不同故障域
• 实测单节点故障与恢复
• Snapshot 定期执行且加密
• 做过 Restore Drill，而不只是"备份任务成功"
• RPO/RTO 有业务负责人确认
• 滚动升级与回滚流程经过预生产验证

安全与多租户

• TLS、Auth、RBAC 和网络边界开启
• Tenant/ACL Filter 在服务端强制注入
• 存在跨租户负向测试
• 日志不会输出原始敏感文档或完整向量
• 删除、保留和审计策略覆盖 Snapshot

成本与治理

• 计算三年 TCO，而不只看首月服务器价格
• 许可和商业功能边界已确认
• 明确 On-call、升级和容量负责人
• 设定扩容、迁移和重新选型触发条件
• 产品版本与配置进入变更管理

15. 最终选择口径

可以用下面四句话快速表达：

• 复杂全文与 Hybrid Search 是核心：优先 Elasticsearch。
• Vector + Payload Filter + Multi-stage 是核心：优先 Qdrant。
• 超大规模分布式 Vector Platform 是核心：优先 Milvus。
• 快速开发、内嵌或中小规模渐进部署是核心：优先 Chroma。

但最终决策必须补上第五句话：

候选系统已在相同数据、相近 Recall、生产副本拓扑、真实过滤和混合读写下完成 POC，并满足 RPO/RTO 与三年 TCO。

Contradictions Or Open Questions

1. 厂商给出的"百万、亿、十亿向量"区间通常建立在特定维度、硬件、索引和负载上，只能用作部署导航，不能代替容量测试。
2. Managed 与 Self-hosted 的差异可能大于两个数据库产品本身的差异；选择时应把两种部署方式视为不同候选项。
3. 各产品对 Hybrid、Quantization、Disk-based Search 和 Multi-tenancy 的实现持续变化，本文的能力矩阵需要随锁定版本复核。
4. "Elasticsearch 全文能力最完整""Qdrant 分布式形态通常比 Milvus 紧凑"等属于基于公开架构的工程判断，不是任意工作负载下的性能结论。
5. 本文未展开 pgvector、OpenSearch、Pinecone、Weaviate、Vespa、Redis Vector 等候选。真实项目若已有相关技术栈，应纳入第一轮基线，而不是强行限定为四选一。

Related Notes

• \[数据库基础-03-向量数据库\|向量数据库基础\]

• \[数据库基础与Agent系统存储\|数据库基础与 Agent 系统存储\]

• \[系统设计核心概念与面试答题框架\|系统设计核心概念与选型框架\]

• \[Redis 扩展数据类型与现代能力\|Redis 的搜索与向量能力边界\]

Sources

Elasticsearch

• Introducing approximate nearest neighbor search in Elasticsearch 8.0
• Dense vector field type
• Dense vector search
• Hybrid search
• GenAI Search High Availability reference architecture

Qdrant

• Hybrid and Multi-Stage Queries
• Storage
• Installation requirements
• Capacity Planning
• Distributed Deployment
• Consistency Guarantees
• Multitenancy
• Production Checklist

Milvus

• Overview of Milvus Deployment Options
• Main Components
• Index Explained
• BM25 Function
• Consistency
• In-Memory Replica

Chroma

• Architecture Overview
• Distributed Architecture
• Full Text Search

所有网页最后核对日期：2026-08-24。