Milvus vs Qdrant / Weaviate / Elasticsearch 架构对比笔记
目标：不是做产品营销式对比，而是从系统架构、状态组织、存储模型和适用工作负载角度比较它们。
1. 先给一句话判断
- Milvus：最像“为向量/混合检索重构过的分布式数据库”，特别强调 segment lifecycle、WAL、控制面/数据面拆分。
- Qdrant：更像“实现相对紧凑、工程上很清晰的向量检索引擎/数据库”，在单集群易用性和一致性工程上很强。
- Weaviate：更像“带 schema/对象模型和上层 AI 功能整合较深的检索数据库平台”。
- Elasticsearch：本质仍是全文检索/通用搜索引擎，向量是其已整合的能力之一，不是最初的核心抽象。
2. 对比应该看什么
如果按数据库内核视角，对比不该只看“支持哪些索引类型”，而该看：
- 核心物理抽象是什么
- mutation 的事实源是什么
- 查询调度有没有专门控制面
- 存储与计算是耦合还是分离
- 后台整理（merge/compaction）如何做
- 向量只是插件能力，还是系统主轴
3. Milvus：segment 驱动的分布式检索数据库
核心抽象
- segment lifecycle
- WAL / streaming
- MixCoord + QueryCoordV2 + QueryNodeV2
- object storage + local cache
- C++ segcore 执行引擎
典型特征
- 控制面和数据面拆分明显
- 远端对象存储是一等公民
- growing/sealed 双路径支撑实时 + 高效查询
- background compaction / index build 体系成熟
- 系统复杂度主要来自 placement 和状态协调
适合什么场景
- 大规模向量数据
- 需要独立扩缩 query / write 资源
- 需要接近数据库级的后台任务和生命周期管理
- 适合 cloud-native / K8s / 多节点环境
不足 / 成本
- 架构复杂，读源码和运维门槛相对更高
- 历史演进痕迹重，理解成本比轻量型产品高
4. Qdrant：更紧凑的向量数据库设计
这里主要给结构化对比视角，不展开具体源码细节。
我对 Qdrant 的结构化印象
- 更强调 per-collection / per-segment 的本地引擎管理
- 分布式能力有，但整体工程体量与抽象层次通常比 Milvus 更集中
- 向量索引与 payload filter 的组合做得很直接
- 从“易理解的检索系统”角度，通常比 Milvus 更容易整体把握
和 Milvus 的最大差异
- Milvus 对控制面拆分更重：QueryCoordV2 / DataCoord / MixCoord / Streaming
- Qdrant 整体往往更像“统一服务中的引擎 + 分片管理”
- Milvus 的 object storage / async flush / segment lifecycle 体系更数据库化
- Qdrant 往往更像“高质量向量引擎 + 分布式扩展”，Milvus 更像“向量导向数据库内核”
什么时候更像 Qdrant 占优
- 希望系统更紧凑、理解更直接
- 更看重部署和工程简洁性
- 数据规模和控制面复杂度没有逼到必须上更重的数据库化拆分
5. Weaviate：对象模型和平台整合感更强
结构印象
Weaviate 的显著特点是：
- 更突出 schema / class / object 层的产品表达
- 更强调上层 AI / embedding / module integration
- 对用户来说“平台感”更强
和 Milvus 的差异
- Milvus 的内部叙事更偏数据库内核：segment、WAL、query coord、data coord
- Weaviate 的外部叙事更偏“AI-native database platform”
- 从底层系统味道看，Milvus 更像 infra/database engineer 的作品；Weaviate 更像平台/应用集成导向更强的系统
什么时候 Weaviate 更顺手
- 需要更多 out-of-the-box AI module / object-level experience
- 更偏应用开发者体验
- 不想直接接触太多底层 segment / query placement 概念
6. Elasticsearch：向量是扩展能力，不是原点
核心抽象
Elasticsearch 的原生世界观仍然是：
- document
- inverted index
- shard
- segment merge
- distributed search / aggregation
向量能力是后来强力集成进去的。
和 Milvus 的本质差异
Elasticsearch 的核心起点
- 先是全文搜索 / 通用搜索平台
- 再把向量检索能力加进来
Milvus 的核心起点
- 先把向量 / 混合检索做成主轴
- 再逐步补 full-text / sparse / BM25
也就是说：
- ES：text-first, vector-added
- Milvus：vector-first, text-being-integrated
结构上的对比
- ES 的 shard/segment/merge 体系极成熟
- ES 在文本检索、聚合分析、生态集成上仍然很强
- Milvus 在大规模向量检索的系统抽象上更专门、更聚焦
- Milvus 的 growing/sealed 路径、QueryCoordV2、Streaming/WAL 等设计，是围绕向量检索实时性和扩展性重做过的
什么时候 Elasticsearch 更合适
- 全文检索、过滤、聚合分析是主需求
- 向量只是增益项
- 生态里已经深度使用 ES/OpenSearch
什么时候 Milvus 更合适
- 向量 / hybrid retrieval 是主 workload
- 需要更系统级的向量生命周期、分布式 query/write 解耦
- 想把向量当一等公民而不是附属字段
7. 一个更直接的架构对照表
| 维度 | Milvus | Qdrant | Weaviate | Elasticsearch |
|---|---|---|---|---|
| 原始核心抽象 | segment + WAL + coord/node | vector segment / shard oriented engine | object/schema + AI modules | document + inverted index + shard |
| 向量是不是主轴 | 是 | 是 | 是 | 不是原始主轴 |
| 控制面拆分程度 | 高 | 中 | 中 | 高，但围绕搜索集群模型 |
| 计算存储分离 | 很强 | 相对没那么激进 | 中 | 通常更偏节点本地存储范式 |
| 对象存储中心性 | 高 | 较低于 Milvus 的中心性 | 中 | 非主叙事 |
| growing / sealed 双路径 | 很突出 | 有类似实时/持久结构，但表述不同 | 相对弱于 Milvus 的系统叙事 | 传统 near-real-time 索引刷新模型 |
| 全文检索传统优势 | 正在补强 | 一般 | 中 | 最强 |
| 系统复杂度 | 高 | 中 | 中 | 高 |
| 最像什么 | 向量数据库内核 | 紧凑型向量数据库/引擎 | AI 平台式向量数据库 | 通用搜索引擎 |
8. 如果从源码学习价值来选
想学“向量数据库如何真正数据库化”
优先看 Milvus。
你会学到：
- WAL / streaming 事实源
- segment lifecycle
- QueryCoord / QueryNode 的 placement 与执行分层
- 异步 index build / compaction / object storage
想学“更紧凑、工程更直接的向量检索系统”
优先看 Qdrant。
想学“AI 平台化数据库产品如何组织能力”
看 Weaviate。
想学“成熟搜索引擎怎样把向量能力收编进来”
看 Elasticsearch。
9. 最后的判断
如果只从“架构深度”和“数据库系统味道”来评价，Milvus 在这几者里最像：
一个为向量/混合检索而重构过的分布式数据库内核。
如果只从“系统紧凑度和易于整体把握”来评价，Qdrant 往往更友好。
如果只从“全文生态和成熟搜索能力”来评价，Elasticsearch 仍然是另一类更强大的传统体系。
因此最合理的结论不是谁全面碾压谁，而是：
- Milvus：最适合研究向量数据库内核化
- Qdrant：最适合研究紧凑型向量系统工程
- Weaviate：最适合研究 AI 平台化产品表达
- Elasticsearch：最适合研究全文系统如何向量化扩展