Milvus：大规模向量数据库 volumes

#Milvus 的目标

大多数向量数据库面向团队项目。Milvus 则面向工业级规模：存储与计算分离，原生支持在 Kubernetes 上水平扩展，并提供多种索引，让用户能够在精度、内存占用和速度之间进行细致权衡。该项目宣称，能够针对数十亿个向量处理数万次查询，同时通过实时流式更新保持数据最新。这是一种架构选择，而非简单的功能集合。

这一雄心也有直接的代价：对于包含五万段文本的语料库，这种强大能力体现不出来，复杂性却立刻显现。因此，需要问的不是“它是不是最好的向量数据库”，而是“我的语料库会不会达到足以让这些设计选择产生影响的规模”。

该项目将自己定位为 AI 开发者值得信赖的基础，用于构建文本和图像搜索应用、检索增强生成应用以及推荐系统，并声称已为众多企业被视为关键的使用场景提供支持。这一定位说明了其目标用户：致力于构建未来可扩展产品的团队，而不是只针对几百个 PDF 文件进行文档检索的个人脚本。

#组件化架构

完整部署时，Milvus 不是单个进程，而是一组组件：查询节点、数据节点、协调服务、对象存储和消息日志。每个组件都可以独立调整规模——项目强调，可以针对高读取负载单独增加查询节点，针对高写入负载单独增加数据节点——这恰好是大规模部署所需要的，也恰好是在工作站上可以省去的。Kubernetes 上的无状态微服务也能在故障后快速恢复；副本支持则通过将数据段加载到多个查询节点上，进一步提高容错能力。正是这种计算与存储的分离，区分了面向工业规模设计的数据库与面向单一服务设计的数据库：即使流量很低，也会持续产生运维成本，而很少有对比评测会在部署前提及这一点。

#使用 Milvus Lite 的最简 Python 用法

1. 01
   连接

   先执行 from pymilvus import MilvusClient，再执行 client = MilvusClient("milvus_demo.db")，即可打开一个存储在本地文件中的数据库；将参数替换为服务器 URI，即可切换到完整部署，其余代码无需修改。
2. 02
   创建一个集合

   client.create_collection(collection_name="demo_collection", dimension=1024) —— 维度必须与您的嵌入模型维度完全一致。
3. 03
   插入数据

   res = client.insert(collection_name="demo_collection", data=data)，其中 data 是一个字典列表，每个字典都包含一个向量及其元数据。
4. 04
   查找

   res = client.search(collection_name="demo_collection", data=vecteurs_requete, limit=5, output_fields=["text"]) 返回与查询向量最接近的五个段落及其指定字段。

该项目强调其与常用 AI 工具——LangChain、LlamaIndex、OpenAI、Hugging Face——的集成；据其作者介绍，这使它成为适合检索增强生成的向量存储。Milvus 既可使用开源嵌入模型，也可通过嵌入服务处理文本、图像和视频，并提供工具（pymilvus[model]），将非结构化数据转换为向量，无需自行编写调用模型的代码，也无需分别管理各供应商的客户端库。

#索引类型与选择

对于本地文档语料库，大多数时候只需记住一个数字：当向量数量少于一百万时，六类索引之间的差异以毫秒计，而不是分钟；花在选择合适设置上的精力，几乎总是投入项目的其他部分更划算。

最能节省时间的建议在任何情况下都一样：先从精确搜索开始。近似索引解决的是规模问题；在尚未遇到这一问题时就采用它们，只会增加参数调优和召回率评估的工作，换来的却是无人察觉的几毫秒提速。Milvus 的文档明确列出了这六类索引——HNSW、IVF、FLAT、SCANN、DiskANN 和量化变体——并说明每一类都针对不同场景进行了优化，还通过 NVIDIA 的 CAGRA 为超大规模数据的索引构建提供 GPU 硬件支持。该项目还为这些索引加入了元数据过滤和范围搜索，对这两项功能的优化与向量搜索本身处于同一水平，而不是将它们实现为会拖慢最终结果的独立层。

#Milvus 在大规模应用中的独特之处

除了索引之外，多个功能解释了为何大型组织更倾向于选择Milvus而非更简单的替代方案。多租户支持四种隔离级别——数据库、集合、分区或分区键——使得单个集群可服务从几十到数百万租户，同时不损失检索性能或访问控制的精细度。热存储和冷存储将频繁访问的数据存入内存或SSD，而将很少访问的数据存入成本更低、速度更慢的存储介质，从而降低总体成本，又不影响关键任务的性能。

在检索方面，Milvus 原生支持基于 BM25 的全文检索，以及 SPLADE 和 BGE-M3 等学习型稀疏嵌入，同时还支持基于稠密向量的语义检索。稀疏向量和稠密向量可以共存于同一集合中，并通过重排序（reranking）功能融合多个查询的结果——这种混合检索在理念上与 Qdrant 提供的功能相似，但这里是围绕 BM25 构建的，而非采用通用的分数融合方式。在安全方面，该项目强调强制身份验证、通信的 TLS 加密以及基于角色的访问控制（RBAC）。当数据库服务于多个应用或多个团队时，这三项都是预期具备的安全措施；而对于仅监听 localhost 的实例，它们的重要性则低得多。

#本地运行：这意味着什么

资源

完整部署需要多个容器和数 GB 内存，这还没有算上您的语言模型：协调服务、查询节点、数据节点、对象存储和消息日志都各自独立运行。

向量的内存占用

全精度下，每个 1 024 维向量约占 4 KB，不包括索引。决定系统架构的是这笔内存账，而不是功能特性——无论使用 Milvus、Qdrant 还是 pgvector，这一点都成立。

运维

备份、版本升级、监控：真正的分布式数据库需要专业的运维人员。Milvus生态系统包括图形化管理界面Attu，以及用于系统调试的Birdwatcher；即便使用这两个工具，仍需要了解底层架构。

GPU 留给模型使用

文档编码和推理已经在争用显卡资源；向量搜索则主要依赖处理器和内存，只有在处理超大规模数据、通过 CAGRA 显式启用 GPU 索引构建时才是例外。

#何时适合选择Milvus

正确的问题从来不是“哪个数据库的功能最多”，而是“我的项目实际会用到其中哪些功能”。四层多租户、冷热存储、基于角色的访问控制（RBAC）和 BM25 混合搜索，是为服务数千名用户且有合规要求的组织而设计的；在个人电脑上，或作为小团队的内部工具使用时，这些机制不会派上用场，但其配置复杂性却依然存在。只有当项目的发展方向——而非当前状态——表明它会在合理的时间范围内出现这些需求时，采用 Milvus 才有充分理由。

• Qdrant：更易运维的专用服务
• pgvector：继续使用 PostgreSQL
• FAISS：程序库，而非服务
• 用 Python 实现的完整 RAG 流程
• QuelLLM 本地 RAG 工具包
• 来源：GitHub 上 Milvus 官方仓库
• 来源：Milvus Lite 官方文档
• 来源：Milvus 分布式架构概览

#FAQ