选择正确的方法来使用Azure Cosmos DB (MongoDB)构建多租户架构

Question

在为MongoDB中的多租户系统在CosmosDB应用程序接口中选择合适的数据库/集合创建方法时，我有点迷惑。我的应用程序有500个租户，每个租户的数据可能增长到3-5 5GB，最初每个租户可能需要最少的RU(400RU/s)。

对于这个用例，我有几个选择: 1. PartitionKey (每个租户) 2.容器具有共享吞吐量(每个租户) 3.容器具有专用吞吐量(每个租户) 4.数据库帐户(每个tanant)

考虑到性能隔离、成本、可用性和安全性，我想知道哪个选项更适合上述用例？请让我知道你的意见，因为我有较少的暴露在NoSQL和宇宙轨道。

Answer 1

答案可能是多个选项，这取决于您的特定租户用例。

租户/分区是最便宜的，每个租户的边际成本为零。这是在你的应用程序中提供“免费层”的一个很好的选择，但你也可以为你的客户扩展到付费层。最大存储大小为20 is。使用此方案，您将需要实现自己的资源治理。您需要确保客户不会“大行其道”，并且消耗的吞吐量和存储空间远远超出了其他用户的要求。但是，如果您正在构建一个多租户应用程序，那么资源治理是您应该已经在做的事情。

租户/容器更贵，每月400 RU/s (25美元/月)，这是容器的最低吞吐量。当您有非常大的租户并且需要与上一层中的其他租户隔离时，这是理想的选择。

租户/账户与租户/容器的边际成本相同。如果您的客户有阻止或要求复制到特定Azure区域的GDPR要求，这将非常有用。

请注意，我不建议租户/容器使用共享数据库吞吐量。原因是，使用此方案，所有容器共享相同的吞吐量，这是您使用租户/分区获得的吞吐量，但是使用共享数据库吞吐量无法预测性能，因此它不是一个好的选择。此外，每个数据库限制为25个容器，这进一步使它成为一个糟糕的选择。

最后，对于您的应用程序，您将需要实现一种将客户从一个层迁移到另一个层的机制。当然，您还需要某种auth-n/auth-z机制。对于Cosmos DB，您可以选择使用我们的本地用户和权限，并使用资源令牌来保护对数据的访问。

在去年的BUILD大会上，我们与Citrix的一位客户就此做了一个演示，他使用Cosmos DB作为他们的用户元数据存储，在Azure上构建了他们自己的云产品。绝对值得一查，并将为您提供更多细节和见解，Mission-critical multi-tenant apps with Cosmos DB

PS:如果你在Cosmos DB上构建一个新的服务，我建议使用我们的核心(SQL)应用编程接口，而不是MongoDB。这是我们的本地服务，您将获得最佳的性能和功能。对于希望迁移并希望获得完全托管的MongoDB体验的客户来说，我们的MongoDB应用程序接口是最佳选择。

希望这能对你有所帮助。