不懂就问,Milvus 新上线的资源组功能到底怎么样?
在近期更新的 Milvus 2.x 版本中,我们上线了在社区中呼声一直很高的【资源组功能】。有了这个功能,用户再也不需要“为每个 collection 部署一套 Milvus 服务”的方案,轻松实现对 Query Node 资源进行分组管理,达到物理资源隔离的效果。
本文将从需求、方案以及实操层面出发,带你详细解读资源组功能。
01.源自用户需求
上线资源组功能的契机来自和用户的一次沟通。
某次,在社区交流活动中,Milvus 的社区用户提出了这样一个问题: 基于 Milvus 部署了多个应用场景,根据数据源和应用场景将数据划分成了多个 Collection。不过,由于向量搜索具备着高度的 CPU 密集型特征,所以在业务的高峰时间段,多个 Collection 的同时查询会争抢 CPU 资源,彼此影响。
为了满足场景需要,用户选择了为每个 Collection 部署一套 Milvus 服务,从数据库的层面来避免查询过程中 Collection 之间的影响。这也是在没有资源组功能时一个比较标准的方案。尽管这套方案完美解决了用户的问题,却也带来了 Milvus 服务运维的开——用户需要同时运维多个 Milvus 集群。因此,在沟通中,用户提出了在一个 Milvus 服务中去实现这个场景的需求。
02.资源隔离方案
Milvus 在提供查询前,需要对 Collection 执行 load 操作,以加速后续查询的速度,实现更好的查询性能。结合 Milvus 用户的使用习惯,我们设计了一套 Milvus 的资源组方案。
Milvus 服务中维护了名为一个 __default_resource_group 的资源组,在 Milvus 启动后,默认所有的 Query Node 都会加入到这个资源组进行管理,后续的 load 操作也会将 Collection 在这个资源组中进行加载。对于不需要感知物理资源的用户,所有的操作、系统表现没有发生任何变化。
如果用户有物理资源隔离的需求,那么可以创建多个自定义资源组,然后将默认资源组中的节点分配转移到自定义的资源组中,实现对 Milvus 集群中 Query Node 资源的划分和物理隔离。随后在 load 操作中,可以去指定每一个 Collection 要加载到哪个资源组中。在加载 Collection 的同时,可实现资源的使用限制。
03.实现 Collection 资源隔离
在介绍完 Milvus 资源隔离的背景和方案后,我们可以通过一个例子来讲述实现 Collection 级别资源隔离的完整步骤。
下面的所有操作是基于用户部署了一个 6 个 Query Node 的 Milvus 服务,所以会有 6 个 Query Node 参与资源隔离过程中的划分和分配。
创建两个自定义资源组和
rg1
和rg2
,用于承载 QueryNode 资源。
分别从 __default_resource_group 中向
rg1
和rg2
转移 3 个节点,实现所有 Query Node 资源的隔离划分。
假定用户有两个需要加载的 Collection, 分别为
Collection A
和Collection B
, 这里通过将Collection A
加载到rg1
, 将Collection B
加载到rg2
, 以此实现Collection A
和Collection B
的资源隔离。
通过上述 3 个步骤,我们实现了 Collection 级别的资源隔离,每个 Collection 使用了 3 个独立的 Query Node, 后续发生在 Collection 上的查询将会使用各自独立的 Query Node, 彼此之间物理隔离,互不影响。
Milvus 通过资源组提供对 Query Node 资源划分的能力,用户可以根据自身的需求灵活安排 Collection 的加载方案,实现各种级别的资源隔离,应对不同的场景和需求。更多关于 Milvus 资源组功能的使用细节,可以点击链接参考 Milvus Doc。
(本文作者刘伟系 Zilliz 高级研发工程师 )
评论