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

2024-08-05

By 郭人通

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

本系列文章介绍

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

08.05——内文图.png 08.05——内文图.png

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、查询节点、索引节点等)。

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

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

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 社区非常开放,一些主要的社区交流入口我都留在了文末。

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

grt1.png grt1.png

图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 灵活。

Milvus Lite,Standalone,Distributed的能力对比

grt2.png grt2.png

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

grt3.png grt3.png

图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 提供更加灵活的部署方式。从数量上看,每一种功能组件都可以部署多个,从而支持更高的负载;从物理资源映射的层面看,不同功能的组件可以被部署到相同物理节点以实现资源共享,或部署到不同物理节点以实现组件间资源隔离;从组件间解耦的层面看,每一种组件都可以进行独立的扩缩容,以适应多样化的负载特征,并有效提高资源利用率。

下期预告

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

  • 郭人通

    郭人通

    准备好开始了吗?

    立刻创建 Zilliz Cloud 集群,存储和检索您的向量。

    免费试用 Zilliz Cloud