Milvus 向量数据库进阶系列丨部署形态选型

本系列文章介绍

在和社区小伙伴们交流的过程中，我们发现大家最关心的问题从来不是某个具体的功能如何使用，而是面对一个具体的实战场景时，如何选择合适的向量数据库解决方案或最优的功能组合。在 “Milvus 向量数据库进阶” 这个系列文章中，我们会聚焦回答这一类问题，如 “在 AI 应用开发的不同阶段，向量数据库应该如何选型”，“如何正确的构建 RAG 多租系统” 等。虽然这个系列名为进阶，但内容同时适用于初级和进阶用户。我们希望通过这些内容的介绍，帮助大家在向量数据库应用的过程中少走弯路。

Milvus 是目前发展最成熟的开源向量数据库项目。和 Qdrant、Weaviate、Chroma 这些近两年的新项目不同，Milvus 为开发者提供了多种部署形态。当然，更多的选择有时候也会带来一些困扰，经常会有同学问怎么选合适的部署形态，今天这篇文章就来和大家详细聊聊这个话题。

现在官方一共提供了三种 Milvus 部署形态：Milvus Lite，Milvus Standalone，Milvus Distributed：

Milvus Lite 可以认为是一个 library 级别的超小型 Milvus。主要面向 python/notebook 环境的快速原型构建、或一些本地的小规模实验。

Milvus Lite 原生集成在 pymilvus 包里，直接 pip install pymilvus，你就在本地完成了 Milvus Lite 的安装。用的时候不需要额外启动服务端，插入数据的持久化都是走的本地文件。

Milvus Standalone 是 Client-Server 模式，是 Milvus 的单机部署形态。Milvus Lite 和 Milvus Standalone 的关系，类似 SQLite 和 MySQL 的关系。Milvus Standalone 的所有组件都打在一个 Docker 镜像里，服务端部署也比较方便。

如果你不是在支持一个大型项目，一般搞一台内存大点儿的机器，部署一套 Milvus Standalone 就够用了。值得提的一点是，Milvus Standalone 支持主备模式高可用，生产环境是可以上的。

Milvus Distributed 是 Milvus 的分布式部署模式。企业用户搭大规模向量数据库系统（或向量数据平台、中台），一般首选这种模式。Milvus Distribute 采用云原生架构，读写分离，关键组件都支持冗余，在三种部署模式中提供最高的扩展性能力和高可用级别，以及组件级的弹性能力（如根据业务负载特征单独扩缩 Proxy、查询节点、索引节点等）。

01.

不同场景下的部署形态选型

一般说选型肯定离不开阶段。用到向量数据库的应用基本有这么几个阶段：

AI 应用的快速原型构建。比如你在做一个 AI 个人助手、一个小的搜索引擎原型、一个端到端的 RAG 原型，这类项目的迭代速度是很关键的，而且原型构建期不需要关心性能或者稳定性这样的指标。因此 Milvus Lite，或 Milvus Lite + Milvus Standalone 会是比较合适的选择。你可以在 notebook 结合 Milvus Lite 快速实现端到端功能搭建，以及面向效果的轻量化实验。

如果你同时也需要在规模大一些的数据集上验证效果，那再起一套 Milvus Standalone 是合适的。注意这里 Milvus Lite 和 Milvus Standalone 并不是独立的两部分，它们支持了一个简单的从笔记本到服务器的工作流：由于 Milvus Lite、Standalone、Distributed 共享一套客户端接口，同样的业务侧代码既可以使用本地数据进行原型开发，也可以链接到服务端进行大规模数据验证。同时 Standalone 支持多用户，一个敏捷开发小组可以使用一套 Milvus Standalone 服务进行协作或共享数据。

早期的生产部署。这里早期指的是项目上线早期，业务访问请求和数据还没有上量、项目还在寻找 Product-market-fit 的阶段。这个阶段你需要关心的仍然是业务效果和业务竞争力，而不是基础设施。因此 Milvus Standalone 是最合适的选择。对于在线业务，需要部署一套主备模式的 Milvus 来保证高可用。对于测试环境，单节点部署即可。

需要注意的是，Milvus Standalone 并不提供表间物理资源隔离。因此如果你有两个业务都很关键且性能敏感，最好把它们的数据通过两套 Milvus Standalone 进行隔离。这可能会带来一些物理资源的浪费，但仍然会比运维 Milvus Distributed 的综合成本低很多。还是那句话，这个阶段你需要聚焦的是业务效果和业务竞争力，而不是基础设施。

当然，这个阶段你仍然可以结合 Milvus Lite 进行一些效果调试工作，特别是面向一些具体用户需求的效果调试。这部分工作不建议在部署 Milvus Standalone 的生产环境进行，这有可能会带来一些潜在的性能和稳定性风险。

大规模生产部署。在这个阶段，你的数据已经超过了单台服务器所能容纳的规模；或数据每天都在快速增长，你需要为后续的业务增长提前做好基础设施的准备。这个时候就需要 Milvus Distributed 登场了。前期会是 Milvus Standalone 和 Milvus Distributed 两套实例并存，我们需要把流量逐步从 Standalone 切换至 Milvus Distributed。并观察至少一个月保证 Milvus Distributed 运行稳定。

这个阶段你也需要逐步完善你的运维系统。Milvus Distributed 原生支持 Prometheus，同时也提供了 Attu 等管理工具。需要注意的是，尽管 Milvus 官方提供了一系列专用运维工具，以及尽可能丰富的生态工具对接，运维一套大型分布式系统并非容事，在这期间你可能会需要比较多的社区帮助。Milvus 社区非常开放，一些主要的社区交流入口我都留在了文末。

02.

不同开源向量数据库的适用数据规模

图 1. 开源向量数据库适用的数据规模

咱们前面主要说的都是 Milvus，这里把其他几个受欢迎的开源向量数据库也拿过来做一个比较。

去年，Chroma 在 AI 个人开发者圈子里比较火。这个项目的特点是聚焦小数据规模，并提供向量数据库功能的最小功能集。如果你的应用只有不到几十万的向量，而且只需要使用数据插入和查询这样的最基本功能，Chroma 可以提供非常轻便的体验。需要注意的是，即便和 Milvus Lite 相比，Chroma 也仅提供了一个功能子集，且并不面向生产。

Weaviate 和 Qdrant 这两个项目更加的 Production Ready。其中，Weaviate 更聚焦 AI 应用对向量数据库的集成，原生提供了一些上游模型的支持。Qdrant 更聚焦向量数据库本身，关注向量查询能力以及性能。（Qdrant 是所有向量数据库项目中，在性能上跟随 Milvus 最紧的一个项目，详见 VectorDB Benchmark）

图 1 对这几个向量数据库的数据规模适用范围进行了比较：

• Milvus Lite 和 Chroma 都适合不超过百万的数据，这个区间的设计考量主要是系统能力和易用性之间的 tradeoff，且更偏向易用性。

• Milvus Standalone、Weaviate、Qdrant 合适的数据规模是百万至小几千万这个范围。在系统能力和易用性之间的设计考量比较平衡。

• Milvus Distributed 合适的数据规模在千万及以上。目前社区已经广泛验证了十亿级规模的场景支持，今年也陆续有百亿级规模的场景落地。

和 Milvus 相比，其他几个项目暂未提供长跨度的部署支持。因此在项目演进的不同阶段会有向量数据库选型切换的成本。对于不同数据规模下的混合工作流的支持也没有 Milvus 灵活。

03.

Milvus Lite，Standalone，Distributed 的能力对比

04.

Milvus Lite，Standalone，Distributed 的组件功能关系

图 2. Lite, Standalone, Distributed 包含的功能组件

Milvus Lite，Standalone，Distributed 之所以能提供一致的使用体验， 并保持相同的演进速度，主要得益于这三种部署模式对底层组件的共享。

上图给出了这三种形态各自覆盖的 Milvus 功能组件：

Milvus Lite 主要是对 Search Engine 的封装，同时对数据写入、持久化、索引构建、元信息管理等必备能力提供了本地实现。这也是为什么 Milvus Lite 可以被视为一个 library 的主要原因。但相比 Chroma 这样具有简易实现的 library，Milvus 的 search engine 无论在性能还是查询能力上都要强悍很多，且更适合嵌入。如果你只是在寻找一个 Faiss 或者 HNWSLib 的替代，Milvus Lite 也是相当合适的。Milvus 查询引擎原生集成了这些主流的向量搜索算法库，整合社区也投入了大量工作进行深度的性能和功能优化。

Milvus Standalone 包含了除负载均衡 (load balancer)、多节点管理 (coordinators) 以外的所有功能组件。这些组件运行在同一个 Docker 环境中，因为所有组件间都是本地通信，因此可以获得很好的服务端延迟。

Milvus Distributed 包含所有功能组件。需要注意的是，Standalone 和 Distributed 虽然都包含 Proxy、Query Node、Data Node、Index Node，且功能相同，但 Distributed 提供更加灵活的部署方式。从数量上看，每一种功能组件都可以部署多个，从而支持更高的负载；从物理资源映射的层面看，不同功能的组件可以被部署到相同物理节点以实现资源共享，或部署到不同物理节点以实现组件间资源隔离；从组件间解耦的层面看，每一种组件都可以进行独立的扩缩容，以适应多样化的负载特征，并有效提高资源利用率。

Milvus 向量数据库进阶系列下期预告

现在市面上的 RAG 系统不管是 to B 的还是 to C 的，基本都需要考虑多租。下一篇我们将结合 Milvus，讲一讲如何构建 RAG 多租户/多用户系统。

作者介绍

郭人通，Zilliz 合伙人和产品总监，CCF 分布式计算与系统专委会执行委员。专注于开发面向 AI 的高效并可扩展的数据分析系统。郭人通拥有华中科技大学计算机软件与理论博士学位。