Java 向量数据库选型：Milvus vs Elasticsearch vs Qdrant

老梁agent
47 阅读3分钟

向量数据库是 RAG 的心脏。Java 生态里怎么选？三种主流方案的实际对比。

为什么不能把向量存在 MySQL？

技术上可以。MySQL 8.0+ 支持 VECTOR 数据类型，也能做 ORDER BY DISTANCE。

但问题是性能：

数据量MySQL (向量)Milvus
100 条10ms1ms
10,000 条200ms5ms
1,000,000 条30s+50ms

向量检索需要 ANN（近似最近邻）索引——像 HNSW、IVF、PQ 这类算法——传统数据库不做这个优化。到百万级向量时，MySQL 基本不可用。

三选一

Java 生态里主流的向量数据库有三个：

MilvusElasticsearchQdrant
定位纯向量数据库搜索引擎 + 向量纯向量数据库
安装Docker（3 容器）Docker（1 容器）Docker（1 容器）
Java 客户端Milvus SDK + LangChain4jElasticsearch Java ClientQdrant Java Client
文本检索需配合 ES原生支持需配合 ES
分布式支持支持支持
GPU 加速支持不支持不支持
LangChain4j 集成✅ 原生支持✅ 原生支持✅ 社区支持
运维复杂度高（3 个容器）中（1 个容器）低（1 个容器）

Milvus：最专业的向量数据库

EmbeddingStore<TextSegment> store = MilvusEmbeddingStore.builder()
        .host("localhost").port(19530)
        .collectionName("industrial_knowledge")
        .dimension(384)
        .build();

优点：

  • 向量检索性能最强，专门为 ANN 优化
  • 支持多种索引类型（HNSW、IVF、DiskANN）
  • LangChain4j 原生集成，配置简单
  • GPU 加速可用于大规模场景

缺点：

  • 部署最复杂——需要 etcd + MinIO + Milvus 三个容器
  • 不支持文本检索（关键词、BM25），需要配合 Elasticsearch 做混合检索
  • 资源占用高，轻量场景杀鸡用牛刀

适合：向量量 >10 万条，纯向量检索场景。

Elasticsearch：最全能的搜索引擎

EmbeddingStore<TextSegment> store = ElasticsearchEmbeddingStore.builder()
        .serverUrl("http://localhost:9200")
        .indexName("industrial_knowledge")
        .dimension(384)
        .build();

优点：

  • 一个服务搞定文本检索 + 向量检索
  • 工业界最成熟的搜索引擎，运维人才多
  • 原生支持 BM25 + Dense → RRF 混合检索
  • 已有 ES 的团队零额外部署成本

缺点：

  • 向量检索性能不如 Milvus（ES 8.x 才加原生向量支持）
  • 内存占用大，JVM 调优复杂
  • 向量维度过高（>1536）时性能下降明显

适合：已有 ES 部署的团队，或者需要文本+向量混合检索。

Qdrant：最简洁的向量数据库

EmbeddingStore<TextSegment> store = QdrantEmbeddingStore.builder()
        .host("localhost").port(6334)
        .collectionName("industrial_knowledge")
        .build();

优点：

  • 单容器部署，最轻量
  • Rust 实现，性能优秀，内存效率高
  • 支持 Payload 过滤（相当于 WHERE 条件）
  • 自带 Web UI 管理界面

缺点：

  • 生态不如 Milvus 和 ES 成熟
  • LangChain4j 支持不如 Milvus 完善
  • 中文社区资料少

适合：中小规模向量量，追求简洁部署。

我的选择：Milvus

对 industrial-agent-long 这个项目，我选了 Milvus，理由很简单：

  1. LangChain4j 原生支持——不需要额外适配。MilvusEmbeddingStore 开箱即用，三行代码搞定连接。
  2. 工业场景会持续增长——从 35 条 → 500 条 → 10000 条检索知识，Milvus 的性能裕量够大。
  3. 混合检索可以后面加——BM25 先不做，等需要时再挂 Elasticsearch，用 RRF 融合结果。

如果让我重新选一次：

  • 小项目（<1000 条向量）→ Qdrant，单容器搞定
  • 已有 ES 的团队→ Elasticsearch，零额外成本
  • 从零搭 RAG 管道→ Milvus，专业且 LangChain4j 集成最好

一句话总结

别把向量存在 MySQL。Milvus 是专业之选，Elasticsearch 是全能之选，Qdrant 是轻量之选。但无论选哪个，先用 35 条数据验证检索管线，再担心百万级的扩展性。

本文由 LaoLiang 原创，首发于掘金/知乎/微信公众号。转载请联系作者。

avatar
文章
阅读
粉丝