我在预览期间一直在将DocumentDB实施到一个多功能系统中。我的计划是为每个签约的租户在DocumentDB帐户下生成一个新数据库。大部分代码已经到位，测试进展顺利。
由于DocumentDB已经正式发布并且文档已经完成，我读到了每个DocumentDB帐户的100个数据库限制，这让我停下来重新思考我的架构。
我想让我的租户保持隔离，以便删除帐户很容易，而且它的组织会非常干净。租户之间的数据不需要互动，因此保持分离不会成为问题。
我的问题：
由于我的目标是将这个规模扩展到数十甚至数十万个租户，因此我需要考虑因DocumentDB限制和/或成本而采用不同的架构吗？
这是否意味着我需要对多个DocumentDB帐户中的每100个帐户进行分片？
根据微软的说法，100个数据库的限制只是一个软限制，可以根据要求扩大规模，但如果需要，它可以达到100,000+吗？如果我获得更多预期的帐户注册并且我的生产限制可能会失去客户，该怎么办？
是否存在这种限制是为了阻止开发人员以这种方式对租户进行分区，这是我应该考虑的充分理由？
答案 0 :(得分：4)
在分割/分割租户数据方面，没有一个通用的答案。通常，对数据进行分区的方式取决于应用程序的查询模式以及每个租户的资源需求（在存储和吞吐量方面）。请记住，集合是DocumentDB的事务和查询边界单元。
将博文发布为上述评论中提到的user272735：Scaling a Multi-Tenant Application with Azure DocumentDB。这是一个很好的阅读。
如果您需要为您的特定方案或数据库/集合限制提供更多1：1指导，请随时在andrl {at} microsoft.com上ping我。