我有一个应用程序已经超出SQL Azure了-无论如何我愿意付出的代价-我对研究Azure DocumentDB感兴趣。预览显然具有明显的可扩展性限制(例如，如here所述)，但是我认为，只要我正确使用它，我就可以摆脱预览期间的限制。
所以这是我的问题。我需要如何设计应用程序以利用Azure DocumentDB的内置可伸缩性？例如，我知道使用Azure Table Storage(一种便宜却可怕的高度受限的替代方案)，您需要按照两步式的层次结构来构造所有数据:PartitionKey和RowKey。只要做到这一点(在现实世界的应用程序中这几乎是不可能的)，ATS(据我所知)就可以在后台在机器之间移动分区，从而获得几乎无限的可扩展性。太棒了，您无需考虑。
使用SQL Server进行扩展显然要复杂得多-您需要设计自己的分片系统，处理确定该分片位于哪台服务器上，等等。可能，并且可以很好地扩展，但又复杂又痛苦。
那么可伸缩性如何与DocumentDB一起使用？它保证了任意的可伸缩性，但是存储引擎如何在后台运行？我看到它具有“数据库”，并且每个数据库可以具有一定数量的“集合”，依此类推。但是其任意可伸缩性如何映射到这些其他概念？如果我有一个包含亿万行的SQL表，那么如果我将所有这些数据放入一个集合中，我是否将获得所需的可伸缩性？还是我需要以某种方式将其手动分散到多个馆藏中？还是跨多个数据库？还是DocumentDB在某种程度上足够智能，可以跨多台机器以一种高效的方式合并查询，而无需我考虑其中的任何一个？或者...？
我一直在环顾四周，但尚未找到有关如何实现此目标的任何指导。对其他人发现的内容或MS建议的内容非常感兴趣。
最佳答案
更新:从2016年4月开始，DocumentDB引入了partitioned collection的概念，它允许您向外扩展并利用服务器端分区。
单个DocumentDB数据库实际上可以扩展到按集合划分的无限数量的文档存储(换句话说，您可以通过添加更多集合来扩展)。
每个集合提供10 GB的存储空间和可变数量的吞吐量(基于性能级别)。集合还提供了文档存储和查询执行的范围；也是其中包含的所有文档的交易域。
资料来源:http://azure.microsoft.com/en-us/documentation/articles/documentdb-manage/
这是我在DocumentDB上为 Multi-Tenancy 应用程序缩放和分区数据时写的link to a blog post。
关于azure - Azure DocumentDB如何扩展？我需要为此担心吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/25578107/