milvus-logo
LFAI
首页
  • 概念

多租户策略

随着 ChatGPT 的普及,越来越多的开发人员开始使用 CVP(ChatGPT、向量数据库、提示)栈创建自己的 SaaS 服务。本指南介绍了如何在全球使用最广泛的向量数据库之一 Milvus 上实现多租户,以跟上这一趋势。

多租户是指一个 Milvus 实例服务多个租户的架构。区分租户的最简单方法是将租户的数据和资源与其他租户的数据和资源分开。每个租户都有自己的专用资源,或与其他租户共享资源,以管理数据库、 Collections 和分区等 Milvus 对象。根据这些对象,有相应的方法来实现 Milvus 多租户。

面向数据库的多租户

自 Milvus 2.2.9 版起,对象数据库开始可用。您可以在一个 Milvus 集群中创建多个数据库。这一新功能使实现面向数据库的多租户成为可能,为每个租户分配一个数据库,这样他们就可以创建自己的 Collections 和分区,充分利用数据。不过,这种策略可以确保租户的数据隔离和搜索性能,但资源可能会浪费在闲置的租户身上。

面向集合的多租户

实现面向 Collection 的多租户有两种可能的方法。

所有租户使用一个 Collection

通过添加租户字段来区分租户,使用单个 Collections 实现多租户是一种简单的选择。在对特定租户进行 ANN 搜索时,添加一个过滤表达式,以过滤掉属于其他租户的所有实体。这是实现多租户的最简单方法。但要注意,过滤器的性能可能会成为 ANN 搜索的瓶颈。

每个租户一个 Collection

另一种方法是为每个租户创建一个 Collection 来存储自己的数据,而不是将所有租户的数据都存储在一个 Collection 中。这可以提供更好的数据隔离和查询性能。不过,请记住,这种方法需要在资源调度、操作能力和成本方面投入更多,如果租户数量超过了单个 Milvus Operator 集群支持的最大集合数,这种方法可能就不适用了。

面向分区的多租户

实现面向分区的多租户也有两种可能的方法:

每个租户一个分区

管理单个 Collection 要比管理多个 Collection 容易得多。与其创建多个 Collections,不如考虑为每个租户分配一个分区,实现灵活的数据隔离和内存管理。面向分区的多租户的搜索性能要比面向 Collection 的多租户好得多。但需要注意的是,Collection 的租户数量不应超过一个 Collection 所能容纳的最大分区数。

基于 Partition Key 的多租户功能

Milvus 2.2.9 引入了一项名为分区密钥的新功能。创建 Collections 时,指定一个租户字段并将其作为 Partition Key 字段。Milvus 将根据分区键字段中的值在分区中存储实体。在进行 ANN 搜索时,Milvus 会根据指定的分区键切换到一个分区,根据分区键过滤实体,并在过滤后的实体中进行搜索。

这种策略解除了 Milvus Collections 可支持的最大租户数限制,并大大简化了资源管理,因为 Milvus 会自动为你管理分区。

总而言之,你可以使用上述任一或某些多租户策略来形成自己的解决方案。下表从数据隔离、搜索性能和最大租户数等方面对这些策略进行了比较。

数据隔离搜索性能最大租户数推荐方案
面向数据库64适用于那些需要集合随项目变化而变化的情况,尤其适用于组织内各部门之间的数据隔离。
一个 Collection 适用于所有项目中等不适用适用于资源有限且对数据隔离不敏感的企业。
每个租户一个 Collections少于 10,000适用于每个群集拥有少于 10,000 个租户的情况。
每个租户一个分区4,096适用于每个 Collections 的租户少于 4,096 个的情况。
基于分区 Key10,000,000+适用于预测租户数量会迅速增加到数百万的用户。

下一步计划

管理数据库Schema

翻译自DeepLogo

想要更快、更简单、更好用的 Milvus SaaS服务 ?

Zilliz Cloud是基于Milvus的全托管向量数据库,拥有更高性能,更易扩展,以及卓越性价比

免费试用 Zilliz Cloud
反馈

此页对您是否有帮助?