为MongoDB Search 构建多租户架构

适用于所有租户的单一集合（推荐）

我们建议应用“所有租户使用一个集合”策略。在此架构中，您将所有租户数据存储在单个数据库内的单个集合中。您可以通过在每个文档中包含 tenant_id字段来区分租户。此字段可以是租户的任何唯一标识符，例如 UUID 或租户名称。

这种集中式方法具有以下优点：

• 减少索引数量

  由于所有租户数据都存储在一个集合中，因此您只需要一个为所有租户提供文档的索引。可以避免达到集群资源限制。示例，您可以在单个索引中包含 tenant_id 和其他共享或租户特定的字段。

• 简化维护操作

  由于只有一个集合存储所有数据，因此您不必维护多个集合或跨多个数据库扩展资源。您还可以简化备份、分片和复制操作，因为您只需针对单个数据库中的单个集合。

• 高效处理查询

  您可以使用 $search.compound.filter 子句中的 等于 操作符在查询中提供 tenant_id 字段作为过滤器。

  注意

  查询结果将仅包含来自匹配租户的文档，从而防止数据跨租户泄漏。

如果您托管的租户股票相似的访问权限模式和资源大小，则此策略还可以使Lucene索引字段数保持较低水平。

如果您的大型租户具有独特的资源或索引需求，请使用视图：

1. 隔离租户。使用带有 操作的 创建视图 $match$expr，以仅使用过滤器过滤租户的文档。

2. 单独索引。在视图上创建MongoDB Search索引。

   这样，您就可以为大型租户自定义索引定义，而不会影响其他租户使用的共享索引。所有其他租户都可以使用单个索引。

   大量索引会在基础集群上产生大量负载，并可能扰乱您的工作负载。单个集群上的搜索索引硬性限制为 2,500。但是，集群可以支持的索引数量取决于集群层和工作负载。由于索引数量少得多，M10 等较小的集群层可能会出现性能下降或内存不足错误的情况。从少量索引开始，并在扩展时监控集群的资源使用情况。

如果您当前应用每个租户一个集合策略，我们建议扩展基础层级，以防止由于大量索引的资源争用而导致复制延迟 OOM 错误增加。我们还建议迁移到所有租户的同一个集合策略。

每个租户一个数据库

在每租户数据库设置中，每个租户都包含自己的数据库。此设置会隔离租户数据，但也会成倍增加集群中的索引数量。如果支持所有租户的数据库超过 2,500，则集群可能会达到 2,500-索引上限。

每个租户一个集合（不推荐）

每个租户的集合策略将每个租户映射到共享数据库中自己的集合。维护每个集合的索引的开销可能会导致：

• 复制延迟增加

• 由于资源争用而导致的 OOM 错误

• 基础层级不稳定

我们不建议对MongoDB Search 使用这种策略，除非租户具有非常可预测的轻量级工作负载。如果您当前使用此策略，迁移到所有租户的一个集合策略。