Azure DocumentDB 多租户架构
Azure DocumentDB Multi-Tenant Architecture
我在多租户系统预览期间一直在实施 DocumentDB。我的计划是在 DocumentDB 帐户下为每个注册的租户生成一个新数据库。大部分代码已经到位，测试进行得非常顺利。
自从 DocumentDB 正式发布并且文档定稿后，我了解到每个 DocumentDB 帐户 100 个数据库的限制，这让我停止重新思考我的架构。
我想让我的租户保持隔离，这样删除帐户就很容易，而且它的组织会非常干净。租户之间的数据不需要交互，因此将其分开不会成为问题。
我的问题：
由于我的目标是将此扩展到数万甚至数十万个租户，我是否需要考虑不同的体系结构，因为 DocumentDB 的限制 and/or 成本？
这是否意味着我需要在多个 DocumentDB 帐户中每 100 个帐户进行一次分片？
根据 Microsoft 的说法，100 个数据库的限制只是一个软限制，可以根据要求扩大，但如果需要，它是否可以增加到 100,000+？如果我获得了预期的更多帐户注册并且我达到了我的生产极限可能会失去客户怎么办？
是否存在此限制以阻止开发人员出于我应该考虑的充分理由以这种方式对租户进行分区？
在分区/分片租户数据方面，没有一刀切的答案。通常，如何对数据进行分区取决于应用程序的查询模式以及每个租户的资源需求（在存储和吞吐量方面）。请记住，集合是 DocumentDB 的事务和查询边界单位。
查看上面评论中提到的 user272735 的博客 post：Scaling a Multi-Tenant Application with Azure DocumentDB。这是一本很棒的书。
如果您需要针对您的特定场景的更多 1:1 指导或 database/collection 放宽限制，请随时通过 andrl {at} microsoft.com.[=11= 联系我]
我在多租户系统预览期间一直在实施 DocumentDB。我的计划是在 DocumentDB 帐户下为每个注册的租户生成一个新数据库。大部分代码已经到位，测试进行得非常顺利。
自从 DocumentDB 正式发布并且文档定稿后，我了解到每个 DocumentDB 帐户 100 个数据库的限制，这让我停止重新思考我的架构。
我想让我的租户保持隔离，这样删除帐户就很容易，而且它的组织会非常干净。租户之间的数据不需要交互，因此将其分开不会成为问题。
我的问题：
由于我的目标是将此扩展到数万甚至数十万个租户，我是否需要考虑不同的体系结构，因为 DocumentDB 的限制 and/or 成本？
这是否意味着我需要在多个 DocumentDB 帐户中每 100 个帐户进行一次分片？
根据 Microsoft 的说法，100 个数据库的限制只是一个软限制，可以根据要求扩大，但如果需要，它是否可以增加到 100,000+？如果我获得了预期的更多帐户注册并且我达到了我的生产极限可能会失去客户怎么办？
是否存在此限制以阻止开发人员出于我应该考虑的充分理由以这种方式对租户进行分区？
在分区/分片租户数据方面，没有一刀切的答案。通常，如何对数据进行分区取决于应用程序的查询模式以及每个租户的资源需求（在存储和吞吐量方面）。请记住，集合是 DocumentDB 的事务和查询边界单位。
查看上面评论中提到的 user272735 的博客 post：Scaling a Multi-Tenant Application with Azure DocumentDB。这是一本很棒的书。
如果您需要针对您的特定场景的更多 1:1 指导或 database/collection 放宽限制，请随时通过 andrl {at} microsoft.com.[=11= 联系我]