Milvus

为十亿级向量而生的云原生向量数据库

更新于 2026-08-28 · 数据来源：GitHub API（采集于 2026-08-28）

一句话定位

把「语义搜索」做成一门数据库工程

开源高性能向量数据库，专为大规模向量 ANN（近似最近邻）检索设计。存储向量 + 标量 + JSON，支撑 RAG、图像搜索、推荐系统等 AI 应用。适合任何需要「按语义找数据」的场景——从单机 pip install 到 K8s 上十亿级向量集群，一套 API 走完。

核心数据

forks 4.2k · open issues 1,332 · 双线维护（v2.6.x 补丁线 + v3.0 特性线，v2.6.23 与 v3.0.0 同月发布）· 学术背书：SIGMOD 2021 系统论文 + VLDB 2022 Manu 论文

传统数据库的「语义鸿沟」

为向量搜索重新造一台数据库

• 向量是一等公民：dense / sparse / 多向量共存于同一 collection，与标量、JSON 一起 CRUD，而非外挂一个索引库
• 云原生即架构：存算分离 + K8s 微服务，读多加 QueryNode、写多加 DataNode，按流量独立伸缩
• 一套 API 三种形态：Milvus Lite（pip 内嵌）→ Standalone（Docker 单机）→ Distributed（K8s 集群），从原型到生产不改代码
• 引擎与系统解耦：核心检索引擎独立，HNSW / IVF / DiskANN / GPU CAGRA 都能插进来按场景选

分布式架构：四层拆解

一条数据的旅程：写入与查询

索引引擎：按场景选武器

另支持 mmap 加载、标量位图 / 跳表索引做过滤加速。v3.0 新增 FAISS 透传索引——直接写 IVF64,Flat 这类 Faiss 索引工厂串，Faiss 配方原样跑在 Milvus 上。

混合检索：稠密 + 稀疏双路召回

纯语义检索会被「同义不同词」骗，纯关键词会被「同词不同义」骗——两路融合是 RAG 检索质量的工业标配，Milvus 把它做进内核而非应用层。

v3.0「Lake-native」：向量库长出数据湖能力

• External Collection：Parquet / Lance / Iceberg / Vortex 数据湖原地建索引搜索，零拷贝不搬家；Milvus 快照本身也能当外部表被批处理系统读
• 在线 Schema 演进：线上加列 / 回填 / 删列不停服——embedding 模型升级、数亿行重算变热路径操作
• SINDI 稀疏索引：learned sparse 检索 QPS 达 MaxScore 约 10 倍；压缩 BM25 索引体积约为 2.6 的 1/3（同等召回）
• Storage V3 (Loon) + Snapshot：manifest 列式存储打底，任意时间点只读快照近零成本
• Woodpecker WAL 独立部署：写路径微服务化，高写入集群可单独扩 WAL
• 检索引擎补全：StructArray 向量子字段混合搜、faceted search（品牌/价格聚合一步到位）、XGBoost L0 重排、TEXT 长文本 LOB 存储

三行代码跑起向量搜索

$ pip install -U pymilvus

# Milvus Lite：内嵌本地文件库，零部署（生产换 uri 即连集群）
from pymilvus import MilvusClient
client = MilvusClient("milvus_demo.db")

client.create_collection("docs", dimension=768)
client.insert("docs", data=[{"id": 1, "vector": emb, "text": "..."}])

res = client.search(
    collection_name="docs",
    data=query_vectors,        # 查询向量，支持批量
    limit=2,                   # TopK
    output_fields=["text"],   # 结果带原始文本
)

Lite → Standalone → Distributed 三种形态共用同一套 MilvusClient API，改一行 uri 从笔记本迁到生产集群。

三种部署形态：从笔记本到十亿向量

另有 Zilliz Cloud 托管版（Serverless / Dedicated / BYOC），官方商业公司运营，不想运维可直接用。

卡位 GenAI 工具链的中心节点

治理：LF AI & Data 基金会毕业项目，Zilliz 主导贡献，中性基金会托管降低厂商锁定顾虑。

适合谁用

• RAG / Agent 记忆：LLM 应用的知识库检索层，需要混合检索 + 实时写入的团队
• 语义搜索 / 图像视频搜索：以图搜图、多模态检索、去重（v3.0 MinHash LSH 原生近重复检测）
• 推荐系统：用户/物品向量召回 + 标量过滤组合，亿级候选库毫秒响应
• 数据基础设施团队：已有数据湖（Parquet/Iceberg），想原地加向量检索而不搬数据——v3.0 External Collection 正对此

需要警惕

• 运维复杂度：Distributed 模式依赖 K8s + etcd + 对象存储 + Pulsar/Woodpecker 多组件，小团队建议 Standalone 或托管版
• 内存成本：HNSW 全内存索引，亿级向量内存开销可观；DiskANN / 量化 / 冷热分层能省但调优门槛仍在
• open issues 1,332：迭代极快（3.0 与 2.6 双线月更），大版本升级需跟紧 release notes，行为变化（如稀疏索引默认算法切换）可能影响既有查询
• 厂商影响：Zilliz 主导开发，方向与商业版 Zilliz Cloud 高度协同——开源协议无风险，但路线图话语权集中

未来空间

向量数据库赛道的定义者之一。v3.0 转向 lake-native——把向量检索嵌进数据湖生态而非自成孤岛，路线判断领先一步。RAG 退潮与否不影响语义检索作为基础设施的长期需求。