构建多租户架构
您可以使用 Atlas 实施多租户，以便应用程序的单个实例为多个租户提供服务。随着时间的推移，随着需求的发展或扩展预期的变化，您最初为多租户架构所做的设计决策可能会产生意想不到的效果。
最佳方法可能取决于以下因素：
预计的扩展需求（租户数量及其数据使用情况）
安全和隔离性要求
租户之间数据需求的统一性或可变性
决定用于多租户架构的最佳方法时，请考虑这些因素。
设计多租户架构时，请考虑以下方法：
说明 | 如果租户数量少且稳定（最多几百个），对数据的要求各不相同，并有严格的访问控制要求，则可考虑每个租户使用一个数据库。 | 如果预计租户数量会无限增长，并且租户之间的数据结构和查询要求相对一致，请考虑让租户的数据共存于单个数据库内的共享集合中。您可以在每个文档中使用 tenantId 字段在租户之间对数据进行逻辑分段。 |
收益分析 |
|
|
Considerations | 您可以：
|
|
重要
安全考虑因素
以下所有方法中，您都是在单个集群中构建多租户架构。您在所有租户之间共享副本 oplog 和用户数据，由此可能会导致潜在的安全问题。如需确保数据分区的安全，必须为每个具有唯一身份验证的租户部署单个小型副本集。
每个租户在自己的数据库中
如果您的租户数量较少且稳定（最多几百个），并且具有不同的数据要求和严格的访问控制要求，则考虑为每个租户创建一个数据库。
此方法具有以下优点：
为了提高安全性，数据库用户可以限制租户的数据访问权限。Atlas 默认限制每个项目最多有 100 个数据库用户。
要考虑跨租户可变数据结构的唯一访问模式，可以设置索引。
要将单个租户转移到自己的专用资源，您可以将整个租户的隔离数据迁移或扩展到新资源（例如另一个集群）。
考虑到您可能：
提高应用程序层的复杂性。
在租户之间创建冗余的集合和索引。
在单个集群中遇到大规模问题。每个新集合和索引所需的基础数据文件都会消耗计算资源。
每个租户在同一个集群中都有自己的逻辑数据库。这种方法既便于定制，又具有很强的安全性。其允许对一个租户进行备份和维护，而不会影响其他租户。
但是这种方法会增加设置工作量和所需的计算资源。租户之间的交互需要连接到多个数据库。某些 MongoDB 命令只能在同一数据库中的集合之间运行。
每个集合和索引都作为单独的文件存储在磁盘上，这可能导致打开的文件数量非常大并且消耗大量内存。为了缓解这种情况，每个节点使用不超过 1000 份数据文件（集合和各个索引）。要了解更多信息，请参阅集合和索引限制。
拥有共享集合的单个数据库中的所有租户
如果您预计租户数量会无限增长，各个租户的数据和查询要求结构相对一致，并且访问控制要求不那么严格，可以考虑使用一个包含所有租户共享集合的单一数据库。
此方法具有以下优点：
高度可扩展（例如，可以对集群进行分片）
简化持续维护（如为新查询模式创建索引）
请考虑以下潜在问题：
单个数据库用户可以访问这个大型多租户数据池。
数据分段是纯逻辑性的，必须在应用程序层中强制执行。
所有租户都可以拥有所有集合的文档。多租户逻辑存在于应用程序层。每个文档都必须有一个 tenantId 字段，每个数据库查询都必须通过该字段进行筛选。您必须在应用程序级别管理安全性。
从长远来看，你可能会遇到扩展问题。你执行的任何维护都会同时影响所有租户。虽然这种方法适用于许多相同规模的小租户，但如果租户规模不同，则效果不佳。此外，你可能会发现为每个租户自定义设置很困难。
在单个数据库中拥有自己的集合的所有租户
避免将所有具有自己集合的租户放入单个数据库。这种方法虽然可以避免定制问题，但会使应用程序代码复杂化，从长期来看会加剧扩展问题。