在处理亿级规模的向量检索时，专用向量数据库 Milvus 相比于 Elasticsearch 展现出显著的性能优势：
- 查询性能 : Milvus 的查询延迟（P99）比 Elasticsearch 低 3-5 倍 ，QPS（每秒查询数）高 4-5 倍。
- 资源效率 : Milvus 的内存效率更高，使用压缩索引（IVF_PQ）后，存储成本可降低 70-80%。
- 根本原因 : 性能差距主要源于编程语言 （C++ vs. Java）、索引算法 （专用优化 vs. 通用实现）、内存管理 （手动 vs. JVM）以及硬件加速（GPU 支持）的根本性差异。
最终推荐 ：对于大规模、高性能的 RAG 应用，采用 Milvus（向量检索）+ Elasticsearch（文本检索） 的混合架构是兼顾性能、成本与扩展性的最佳实践。
引言：RAG 时代的"甜蜜烦恼"
随着检索增强生成（RAG）成为构建高级 AI 应用的主流范式，向量检索的需求呈爆炸式增长。当文献库从十万级迈向千万级，向量数据库中的数据量也随之从百万级飙升至亿级。此时，一个关键的技术抉择摆在了所有架构师面前：是继续依赖我们熟悉的"瑞士军刀" Elasticsearch ，还是转向更专业的"屠龙刀" Milvus？
这个问题不仅仅是工具选择，更关乎系统的性能上限、成本控制和未来的可扩展性。本文将基于一个真实的亿级医学文献向量检索场景，深度剖析 Elasticsearch 与 Milvus 之间的性能鸿沟，并为您提供清晰的架构选型建议。
两位选手：通用巨头 vs. 向量新贵
Elasticsearch
Elasticsearch 是一个基于 Lucene 库的分布式搜索和分析引擎。自 8.0 版本以来，它通过引入 HNSW（Hierarchical Navigable Small World）算法原生支持了向量检索（kNN），使其成为一个强大的混合检索引擎 [1]。
- 优势: 成熟的生态、强大的文本检索能力（BM25）、丰富的聚合与过滤功能。
- 定位: 通用型搜索引擎，向量检索是其扩展能力之一。
Milvus
Milvus 是一个专为大规模向量相似度搜索而设计的开源向量数据库。它从底层开始就为高性能向量检索而构建，提供了丰富的索引算法和灵活的部署选项 [2]。
- 优势: 极致的向量检索性能、高可扩展性、支持 GPU 加速、丰富的索引类型（HNSW, IVF-PQ, etc.）。
- 定位: 专用向量数据库，专注于解决向量检索的核心问题。
性能对决：在亿级赛场上一较高下
为了量化性能差距，我们设定一个典型的 RAG 场景：
- 数据规模: 2 亿个 Chunks（来自 1000 万篇文献）
- 向量维度: 1024 维（BGE-Large-zh-v1.5 模型）
- 硬件配置: 32 核 CPU, 128 GB RAM 的云服务器
Round 1: 索引性能（Indexing Performance）
索引性能决定了数据从产生到可被检索的时间，对于需要频繁更新的系统至关重要。
| 指标 | Elasticsearch | Milvus | 性能差距 |
|---|---|---|---|
| 全量索引时间 | ~10-12 天 | ~3-5 天 | Milvus 快 2-3 倍 |
| 内存占用（索引构建） | 高（易 OOM） | 中（可控） | Milvus 更稳定 |
差距根源:
- Java GC 开销: Elasticsearch 在大规模索引构建过程中，JVM 的垃圾回收（GC）会产生显著开销，甚至引发长时间的"Stop-the-World"暂停，严重影响索引速度 [3]。
- C++ 原生性能: Milvus 基于 C++ 实现，没有 GC 开销，内存管理更精细，能更充分地利用硬件资源进行并行构建。
Round 2: 查询性能（Query Performance）
查询性能是 RAG 系统用户体验的核心，直接影响答案生成的速度和质量。
| 指标 | Elasticsearch (HNSW) | Milvus (HNSW, CPU) | Milvus (IVF_PQ, GPU) | 性能差距 |
|---|---|---|---|---|
| 查询延迟 (P99, Top-50) | 200-500 ms | 50-150 ms | < 30 ms | Milvus 快 3-15 倍 |
| QPS (单节点) | 50-100 | 200-500 | 1000+ | Milvus 高 4-10 倍 |
| 内存占用 (查询时) | ~800 GB (2x 向量数据) | ~400 GB (1x 向量数据) | ~200 GB (压缩后) | Milvus 节省 50-75% |
差距根源:
- 算法实现 : Milvus 的 HNSW 算法是基于
hnswlib深度优化的 C++ 实现，相比 Lucene 的通用 Java 实现，在图遍历和距离计算上效率更高 [4]。 - 内存效率: Milvus 的索引结构更紧凑，且支持量化（Quantization）技术，如 IVF_PQ，可以将向量压缩 4-8 倍，大幅降低内存占用，同时保持高召回率。
- GPU 加速: Milvus 可以利用 GPU 的大规模并行计算能力，将向量检索速度提升一个数量级，这是 Elasticsearch 目前无法做到的。
Round 3: 扩展性与成本（Scalability & Cost）
| 维度 | Elasticsearch | Milvus |
|---|---|---|
| 架构 | 紧耦合（数据与计算节点绑定） | 存算分离（支持对象存储） |
| 扩展性 | 复杂（需要手动管理分片和副本） | 简单（云原生架构，自动扩缩容） |
| 存储成本 | 高（需昂贵的本地 SSD） | 低（可使用廉价的对象存储） |
差距根源:
- 存算分离 : Milvus 的架构允许将全量数据存储在 S3/OSS 等对象存储中，仅将热数据或索引加载到计算节点的内存中。这使得存储成本可以降低 50-70% [5]。而 Elasticsearch 的数据和计算紧密耦合，需要为所有数据配备昂贵的本地存储和高内存节点。
性能鸿沟的背后：架构与基因的差异
为什么 Milvus 能在向量检索上全面超越 Elasticsearch？答案在于它们的"基因"。
| 维度 | Elasticsearch | Milvus | 根本差异 |
|---|---|---|---|
| 1. 编程语言 | Java (JVM) | C++ (原生) | GC vs. 手动内存管理: C++ 在计算密集型任务中无 GC 停顿，内存访问更直接高效。 |
| 2. 核心引擎 | Lucene (通用文本引擎) | Knowhere (专用向量引擎) | 通用 vs. 专用: Knowhere 专为向量优化，深度整合了 Faiss, HNSWlib 等库。 |
| 3. 硬件利用 | 仅 CPU | CPU + SIMD + GPU | 充分压榨硬件: Milvus 利用 SIMD 指令集 (AVX2/AVX-512) 和 GPU 加速向量计算。 |
| 4. 社区生态 | 搜索、日志、分析 | AI, RAG, CV | 生态焦点不同: Milvus 的生态完全围绕 AI 和向量应用构建。 |
正如 Zilliz 的一篇博客所指出的："Elasticsearch 是一个在通用搜索引擎上添加了向量功能的系统，而 Milvus 是一个从头开始构建的专用向量数据库。" [6]
这种基因上的差异，决定了在亿级向量检索的专业赛道上，Milvus 必然会胜出。
最佳实践：鱼与熊掌兼得的混合架构
既然两者各有优势，我们是否可以取长补短？答案是肯定的。Milvus + Elasticsearch 的混合架构是当前大规模 RAG 应用的最佳实践。
ES集群
Milvus集群
分发
分发
Top-K 向量结果
Top-K 文本结果
RRF 融合
最终上下文
用户查询
向量检索
BM25 + 元数据过滤
应用层
Reranker 精排
LLM 生成答案
架构优势:
- 发挥专长: Milvus 专注于其最擅长的向量相似度搜索，提供极致的性能和效率。
- 保留优势: Elasticsearch 继续承担其强大的全文检索（BM25）和复杂的元数据过滤任务。
- 灵活融合: 在应用层通过倒数排名融合（RRF）等策略合并两路召回结果，兼顾语义相关性和关键词匹配度。
- 成本优化: ES 集群的规模可以大幅缩减，因为它不再需要承载巨大的向量索引和计算压力，从而显著降低总拥有成本（TCO）。
结论
在向量检索的浪潮中，没有一招鲜吃遍天的银弹。对于百万级以下的中小规模场景，Elasticsearch 凭借其便利性和强大的混合检索能力，依然是一个不错的选择。
然而，当您的业务迈向千万级文献、亿级向量 的规模时，性能、成本和扩展性的瓶颈将变得不可忽视。此时，将向量检索的重任交给专用的向量数据库 Milvus，并与 Elasticsearch 协同工作，无疑是更明智、更具前瞻性的架构选择。
从"能用"到"好用"，再到"高效"，是每个大规模 AI 应用的必经之路。在向量检索这个核心环节上，选择正确的工具，将为您的系统构建坚实的性能基石。
参考文献
1\] Elasticsearch. (2023). *Vector search and kNN* .