Scaling limits with collections
v1.30如果您看到一个错误，提示已达到集合数量限制，这意味着您无法创建更多集合。此限制旨在确保 Weaviate 保持高性能。如果您的实例已经超过了限制，Weaviate 将不允许创建任何新的集合。现有的集合不会被删除。
不要仅仅提高限制，请考虑重新思考您的架构。如果您确实需要更改限制，请使用 MAXIMUM_ALLOWED_COLLECTIONS_COUNT 环境变量。
本指南概述了使用多租户或为每个数据集定义专用集合的可用架构选择。
考虑一个开发者正在创建一个用于产品推荐的 SaaS 平台，该平台允许最终用户（商家）向他们的购物者推荐产品的情况。在这种情况下，每个商家将只上传和使用他们自己的数据。
一种选择是开发者为每个商家的数据集创建一个专用集合。但是，随着商家数量的增长，集合的数量也会增加，这可能会导致性能瓶颈和运营复杂性增加。这引出了一个重要的架构问题：您应该使用“多租户”还是“每个数据集一个集合”？
选择正确的架构
在 Weaviate 中设计向量数据库集合定义（数据模式）时，您必须决定在多租户（将多个租户的数据存储在单个集合中）或创建为每个数据集创建单独的集合（“每个数据集一个集合”策略）之间进行选择。每种方法都有其自身的优点和权衡，尤其是在性能、可扩展性和管理方面。
本指南旨在阐明这些概念并突出每种方法的含义，重点介绍优点和缺点
“每个数据集一个集合”架构
在这种方法中，每个数据集都被分配一个专用的集合，以确保它们之间的数据分离。在 Weaviate 中实现多租户之前，这是管理多个数据集的最佳方法。
当一家书店在我们的平台上注册时，我们会创建集合
BookStoreProducts。这允许商店自定义集合并添加特定于其电子商务平台的属性，例如作者、标题、类型等。
为每个数据集创建新的集合（ShoeStoreProducts、 GameStoreProducts 等）可能看起来像一种简单有效的保持数据隔离的方法。但是，随着平台的扩展，这种方法很快会遇到重大挑战。
“每个数据集一个集合”架构示例。
优点
- 可定制性：集合定义更改或优化可以针对单个集合定制，而不会影响其他集合。
- 数据隔离：数据集通过使用专用集合完全分离。
挑战
- 资源开销：每个集合都需要自己的定义、索引和存储，从而导致内存和磁盘使用量增加。管理数百万甚至数千个集合几乎是不可能的。
- 运营复杂性：集合定义更改必须单独应用于每个集合。每个集合都必须单独更新，这需要大量的时间和计算工作。
如果您正在创建超过 20 个集合，请花点时间考虑是否可以使用多租户。
多租户架构
多租户是指将单个集合划分为多个数据集（租户）。每个租户的数据通过使用租户名称进行逻辑隔离。当您想为多个客户存储数据或为多个项目存储类似结构的数据时，多租户尤其有用。
每个租户由其名称标识，确保其产品在同一个集合中保持逻辑分离。当“书店”在我们的平台上注册时，我们可以在集合 Products 中创建一个名为
BookStore 的新租户。
查询也可以根据名称进行过滤，以仅检索相关数据。
优点
当您需要支持大量租户并优先考虑资源效率和可扩展性时，请使用多租户。
- 更轻松的集合定义管理：定义更新普遍适用于所有租户。例如，现在为所有产品添加新属性要容易得多。
- 索引可扩展性：索引可以针对单个集合进行优化，而不是分散到多个集合中。每个租户都有一个专用的高性能向量索引，从而实现更快的查询速度。与搜索共享索引空间相比，每个租户都响应得好像它是集群上唯一的用户一样。
- 数据隔离：每个租户的数据完全隔离。这意味着数据删除也更容易更快。
挑战
- 访问控制复杂性：细粒度访问控制必须实施，以确保租户之间的数据隔离。
- 统一的集合定义：所有租户必须共享相同的集合模式和配置。
结论
虽然在多租户和专用集合之间进行选择取决于您的具体用例，但多租户的显著性能优势使其成为大多数场景的首选方法。通过多租户，您可以通过减少索引开销和简化所有租户的集合定义更新来获得显著的资源效率。
虽然专用集合在某些情况下可以提供增强的数据隔离性和灵活性，但它们的运营复杂性和增加的资源需求通常超过这些好处。定期监控查询性能、索引大小和资源利用率对于微调您的架构至关重要，以确保它满足当前和未来的需求。
更多资源
要了解有关多租户的更多信息，请访问以下页面
问题和反馈
如果您有任何问题或反馈，请在 用户论坛 中告诉我们。