Docs 菜单
Docs 主页
/
MongoDB Atlas
/

构建多租户架构

在此页面上

  • 每个租户在自己的数据库中
  • 拥有共享集合的单个数据库中的所有租户
  • 在单个数据库中拥有自己的集合的所有租户

您可以使用 Atlas 实施多租户,以便应用程序的单个实例为多个租户提供服务。随着时间的推移,随着需求的发展或扩展预期的变化,您最初为多租户架构所做的设计决策可能会产生意想不到的效果。

最佳方法可能取决于以下因素:

  • 预计的扩展需求(租户数量及其数据使用情况)

  • 安全和隔离性要求

  • 租户之间数据需求的统一性或可变性

决定用于多租户架构的最佳方法时,请考虑这些因素。

设计多租户架构时,请考虑以下方法:

每个租户在自己的数据库中

说明

如果租户数量少且稳定(最多几百个),对数据的要求各不相同,并有严格的访问控制要求,则可考虑每个租户使用一个数据库。

如果预计租户数量会无限增长,并且租户之间的数据结构和查询要求相对一致,请考虑让租户的数据共存于单个数据库内的共享集合中。您可以在每个文档中使用 tenantId 字段在租户之间对数据进行逻辑分段。

收益分析

  • 数据库用户可以限制租户数据访问。

  • 您可以设置索引,以考虑跨租户的可变数据结构的独特访问模式。

  • 您可将整个租户的隔离数据迁移或扩展到新资源。

  • 高度可扩展

  • 简化持续维护

Considerations

您可以:

  • 提高应用程序层的复杂性。

  • 在租户之间创建冗余的集合和索引。

  • 在单个集群中遇到大规模问题。

  • 单个数据库用户可以访问这个大型多租户数据池。

  • 数据分段是纯逻辑性的,必须在应用程序层中强制执行。

避免 所有租户在单个数据库中都有自己的集合。

重要

安全考虑因素

以下所有方法中,您都是在单个集群中构建多租户架构。您在所有租户之间共享副本 oplog 和用户数据,由此可能会导致潜在的安全问题。如需确保数据分区的安全,必须为每个具有唯一身份验证的租户部署单个小型副本集。

提示

另请参阅:

如果您的租户数量较少且稳定(最多几百个),并且具有不同的数据要求和严格的访问控制要求,则考虑为每个租户创建一个数据库。

此方法具有以下优点:

  • 为了提高安全性,数据库用户可以限制租户的数据访问权限。Atlas 默认限制每个项目最多有 100 个数据库用户

  • 要考虑跨租户可变数据结构的唯一访问模式,可以设置索引。

  • 要将单个租户转移到自己的专用资源,您可以将整个租户的隔离数据迁移或扩展到新资源(例如另一个集群)。

考虑到您可能:

  • 提高应用程序层的复杂性。

  • 在租户之间创建冗余的集合和索引。

  • 在单个集群中遇到大规模问题。每个新集合和索引所需的基础数据文件都会消耗计算资源。

每个租户在同一个集群中都有自己的逻辑数据库。这种方法既便于定制,又具有很强的安全性。其允许对一个租户进行备份和维护,而不会影响其他租户。

但是这种方法会增加设置工作量和所需的计算资源。租户之间的交互需要连接到多个数据库。某些 MongoDB 命令只能在同一数据库中的集合之间运行。

每个集合和索引都作为单独的文件存储在磁盘上,这可能导致打开的文件数量非常大并且消耗大量内存。为了缓解这种情况,每个节点使用不超过 1000 份数据文件(集合和各个索引)。要了解更多信息,请参阅集合和索引限制

如果您预计租户数量会无限增长,各个租户的数据和查询要求结构相对一致,并且访问控制要求不那么严格,可以考虑使用一个包含所有租户共享集合的单一数据库。

此方法具有以下优点:

  • 高度可扩展(例如,可以对集群进行分片)

  • 简化持续维护(如为新查询模式创建索引)

请考虑以下潜在问题:

  • 单个数据库用户可以访问这个大型多租户数据池。

  • 数据分段是纯逻辑性的,必须在应用程序层中强制执行。

所有租户都可以拥有所有集合的文档。多租户逻辑存在于应用程序层。每个文档都必须有一个 tenantId 字段,每个数据库查询都必须通过该字段进行筛选。您必须在应用程序级别管理安全性。

从长远来看,你可能会遇到扩展问题。你执行的任何维护都会同时影响所有租户。虽然这种方法适用于许多相同规模的小租户,但如果租户规模不同,则效果不佳。此外,你可能会发现为每个租户自定义设置很困难。

避免将所有具有自己集合的租户放入单个数据库。这种方法虽然可以避免定制问题,但会使应用程序代码复杂化,从长期来看会加剧扩展问题。

后退

恢复时间点