多租户策略
随着 ChatGPT 的普及，越来越多的开发人员开始使用 CVP（ChatGPT、向量数据库、提示）栈创建自己的 SaaS 服务。本指南介绍了如何在全球使用最广泛的向量数据库之一 Milvus 上实现多租户，以跟上这一趋势。
多租户是指一个 Milvus 实例服务多个租户的架构。区分租户的最简单方法是将租户的数据和资源与其他租户的数据和资源分开。每个租户都有自己的专用资源或与其他租户共享资源，以管理数据库、Collection 和 Partition 等 Milvus 对象。根据这些对象，有相应的方法来实现 Milvus 多租户。
面向数据库的多租户
自 Milvus 2.2.9 版起，对象数据库开始可用。你可以在一个 Milvus 集群中创建多个数据库。这项新功能可以为每个租户分配一个数据库，从而实现面向数据库的多租户，这样租户就可以创建自己的 Collection 和 Partition，充分利用自己的数据。不过，这种策略可以确保租户的数据隔离和搜索性能，但资源可能会浪费在闲置的租户身上。
面向 Collection 的多租户
实现面向 Collection 的多租户有两种可能的方法。
所有租户使用一个 Collection
通过添加租户字段来区分租户，使用单个 Collection 来实现多租户是一种简单的选择。在对特定租户进行 ANN 搜索时，添加一个过滤表达式，以过滤掉属于其他租户的所有实体。这是实现多租户的最简单方法。但要注意，过滤器的性能可能会成为 ANN 搜索的瓶颈。
每个租户一个 Collection
另一种方法是为每个租户创建一个 Collection 来存储自己的数据，而不是将所有租户的数据存储在一个 Collection 中。这可以提供更好的数据隔离和查询性能。不过，请记住，这种方法需要在资源调度、运行能力和成本方面投入更多，如果租户数量超过了单个 Milvus 集群支持的最大 Collection 数，这种方法可能就不适用了。
面向 Partition 的多租户
实现面向 Partition 的多租户也有两种可能的方法：
每个租户一个 Partition
管理单个 Collection 比管理多个 Collection 容易得多。与其创建多个 Collection，不如考虑为每个租户分配一个 Partition，以实现灵活的数据隔离和内存管理。面向 Partition 的多租户搜索性能比面向 Collection 的多租户要好得多。但需要注意的是，Collection 的租户数量不应超过 Collection 可容纳 Partition 的最大数量。
基于 Partition Key 的多租户
Milvus 2.2.9 引入了名为 Partition Key 的新功能。创建 Collection 时，指定一个租户字段并将其作为 Partition Key 字段。Milvus 将根据 Partition Key 字段中的值在 Partition 中存储实体。在进行 ANN 搜索时，Milvus 会根据指定的 Partition Key 切换到一个 Partition，根据 Partition Key 过滤实体，并在过滤后的实体中进行搜索。
这种策略取消了 Milvus Collection 可支持的最大租户数限制，并大大简化了资源管理，因为 Milvus 会自动为你管理 Partition。
总而言之，你可以使用上述任一或某些多租户策略来形成自己的解决方案。下表从数据隔离、搜索性能和最大租户数等方面对这些策略进行了比较。
| 数据隔离 | 搜索性能 | 最大租户数 | 推荐方案 | |
|---|---|---|---|---|
| 面向数据库 | 强 | 强 | 64 | 适用于需要 Collection 随项目变化而变化的情况，尤其适用于组织内各部门之间的数据隔离。 |
| 一个 Collection 适用于所有项目 | 弱 | 中等 | 不适用 | 适用于资源有限且对数据隔离不敏感的企业。 |
| 每个租户一个 Collection | 强 | 强 | 少于 10,000 | 适用于每个群集拥有少于 10,000 个租户的情况。 |
| 每个租户一个 Partition | 中 | 强 | 4,096 | 适用于每个集群租户少于 4 096 个的情况。 |
| 基于 Partition Key | 中 | 强 | 10,000,000+ | 适用于预测租户数量会迅速增加到数百万的用户。 |