azure - Azure DocumentDB 如何扩展？我需要担心吗？

Question

我的应用程序已经无法满足 SQL Azure 的需求 - 无论如何，我愿意支付这个价格 - 并且我有兴趣研究 Azure DocumentDB。预览版显然具有明显的可扩展性限制(例如，如 here 中所述)，但我认为，如果我正确使用它，我可能可以在预览期间摆脱这些限制。

这就是我的问题。我需要如何设计应用程序才能利用 Azure DocumentDB 的内置可扩展性？例如，我知道使用 Azure 表存储(一种便宜但 糟糕 高度有限的替代方案)- 您需要在两步层次结构中构建所有数据:PartitionKey 和 RowKey。如果您这样做(这在现实世界的应用程序中几乎是不可能的)，ATS(据我所知)会在幕后将分区从一台机器移动到另一台机器，以便您获得近乎无限的可扩展性。太棒了，你永远不必考虑它。

使用 SQL Server 进行扩展显然要复杂得多 - 您需要设计自己的分片系统，确定相关分片位于哪个服务器上，等等。可能，而且做得好的话，相当可扩展，但复杂且痛苦。

那么 DocumentDB 的可扩展性如何发挥作用呢？它 promise 任意的可扩展性，但存储引擎在幕后如何工作？我看到它有“数据库”，每个数据库可以有一定数量的“集合”，等等。但它的任意可扩展性如何映射到这些其他概念呢？如果我有一个包含数亿行的 SQL 表，如果我将所有这些数据放入一个集合中，我是否可以获得所需的可伸缩性？或者我是否需要手动将其分布在多个集合中，以某种方式进行分片？或者跨多个数据库？或者 DocumentDB 是否足够智能，能够以高性能的方式跨多台机器合并查询，而无需我考虑任何一个？或者...？

我一直在四处寻找，但尚未找到任何有关如何解决此问题的指导。对其他人的发现或 MS 的建议非常感兴趣。

Answer 1

更新:自 2016 年 4 月起，DocumentDB 引入了 partitioned collection 的概念。它允许您横向扩展并利用服务器端分区。

单个 DocumentDB 数据库实际上可以扩展到按集合分区的无限量文档存储(换句话说，您可以通过添加更多集合进行扩展)。

每个集合提供 10 GB 的存储空间和可变的吞吐量(基于性能级别)。集合还提供文档存储和查询执行的范围；也是其中包含的所有文档的事务域。

来源:http://azure.microsoft.com/en-us/documentation/articles/documentdb-manage/

这是一个link to a blog post我撰写了有关 DocumentDB 上 Multi-Tenancy 应用程序的扩展和分区数据的文章。