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

Question

在 CosmosDB API 中为 MongoDB 中的多租户系统选择合适的方法创建数据库/集合时，我几乎没有感到困惑。我的应用程序将有 500 个租户，其中每个租户的数据可能会增长到 3-5GB，并且最初每个租户可能需要最小 RU (400 RU/s)。

对于这个用例，我几乎没有选择： 1. PartitionKey（每个租户） 2. 具有共享吞吐量的容器（每个租户） 3. 具有专用吞吐量的容器（每个租户） 4. 数据库帐户（每个 tanant）

考虑到性能隔离、成本、可用性和安全性，我是否知道哪个选项适合上述用例？请让我知道您的意见，因为我对 NoSQL 和 Cosmos 轨道的接触较少。

Answer 1

答案可能有多种选择，这取决于您的特定租户用例。

租户/分区是最便宜的，每个租户的边际成本为零。这是在您的应用程序中提供“免费层”的一个很好的选择，但您也可以将其扩展为您的客户的付费层。最大存储大小为 20GB。使用此方案，您将需要实施自己的资源治理。您将需要确保客户不会“过热”并消耗与其他用户完全不同的吞吐量和存储。但是，如果您正在构建一个多租户应用程序，资源治理是您应该已经在做的事情。

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

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

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

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

去年，我们在 BUILD 上与我们的 Citrix 客户就这一点进行了演示，该客户使用 Cosmos DB 作为用户元数据存储在 Azure 之上构建了自己的云产品。绝对值得一试，并将为您提供更多详细信息和见解，使用 Cosmos DB 的任务关键型多租户应用程序

PS：如果您要在 Cosmos DB 上构建新服务，我建议使用我们的 Core (SQL) API 而不是 MongoDB。这是我们的原生服务，您将获得最佳性能和功能。对于希望迁移并希望获得完全托管的 MongoDB 体验的客户，我们的 MongoDB API 是最佳选择。

希望这是有帮助的。