我有一个超出 SQL Azure 的应用程序——无论如何，我愿意付出的代价——我对调查 Azure DocumentDB 很感兴趣。预览版显然具有明显的可扩展性限制（例如，如此处所述），但我认为如果我正确使用它，我可能会在预览期间摆脱这些限制。
所以这是我的问题。如何设计我的应用程序以利用 Azure DocumentDB 的内置可伸缩性？例如，我知道使用 Azure 表存储——这种廉价但非常有限的替代方案——你需要在两步层次结构中构建所有数据：PartitionKey 和 RowKey。如果您这样做（这在现实世界的应用程序中几乎是不可能的），ATS（据我所知）在幕后移动分区，从一台机器到另一台机器，以便您获得近乎无限的可扩展性。太棒了，你永远不必考虑它。
使用 SQL Server 进行横向扩展显然要复杂得多——您需要设计自己的分片系统，处理确定有问题的分片位于哪个服务器上，等等。可能，并且做得很好，可扩展性很强，但复杂而痛苦。
那么可伸缩性如何与 DocumentDB 一起使用呢？它保证了任意的可扩展性，但是存储引擎在幕后是如何工作的呢？我看到它有“数据库”，每个数据库都可以有一些“集合”，等等。但它的任意可扩展性如何映射到这些其他概念？如果我有一个包含数亿行的 SQL 表，如果我将所有这些数据放入一个集合中，我是否可以获得所需的可伸缩性？还是我需要手动将它分布在多个集合中，以某种方式分片？还是跨多个数据库？或者 DocumentDB 是否足够聪明，可以以一种高效的方式跨多台机器合并查询，而无需我考虑任何事情？或者...？
我一直在环顾四周，但尚未找到有关如何解决此问题的任何指导。对其他人发现的内容或 MS 推荐的内容非常感兴趣。