我有一些关于扩展Cosmos DB的问题，我无法使用官方文档进行验证。 像userid这样的分区键将每个唯一的用户ID放入一个逻辑分区，并且该分区存储在一个物理分区中。对于具有类似2500-5000 RU / s的集合，cosmos db提供10个物理分区，每个分区的吞吐量为250-500 RU / s。如果我错了，请纠正我。另一点：我对使用DocumentDB-API的Cosmos DB感兴趣。
现在的问题是：Cosmos数据库的自动缩放是如何工作的？我猜他们会以任何方式扩展物理分区，但这究竟是如何工作的。如果一个物理分区达到其吞吐量，是否有任何缩放？将消耗大量吞吐量的逻辑分区移动到具有可用吞吐量的另一个物理分区中吗？如果一个物理分区达到其存储限制会发生什么？ Cosmos db会提供更多物理分区吗？如果是，最大吞吐量将被分成当前物理分区的数量，到目前为止是否正确？
答案 0 :(得分：3)
我爱来自Cosmos DB团队的人提供权威的答案。尽管微软指出了Stackoverflow的问题，但我还没有看到官方的答案。话虽这么说，这是我试图回答的问题。
对于类似2500-5000 RU / s的集合，cosmos db提供10个物理分区，每个分区的吞吐量为250-500 RU / s。
最初有10个物理分区。但这并没有在任何地方记录。
如果一个物理分区达到其吞吐量，是否有任何缩放？
不，只有在达到分区的存储限制时才会拆分分区（看起来是10GB）。
消耗大量吞吐量的逻辑分区是否会被移动到具有可用吞吐量的另一个物理分区？
没有
如果一个物理分区达到其存储限制会发生什么？ Cosmos db会提供更多物理分区吗？如果是，最大吞吐量将被分成当前物理分区的数量，到目前为止是否正确？
从文档：当物理分区p达到其存储限制时，Cosmos DB将p无缝地拆分为两个新分区p1和p2，并将对应于大约一半密钥的值分配给每个分区。此拆分操作对您的应用程序不可见。
你没有每分钟提到RU，这是系统的一个非常重要的方面。似乎RU / m在任何分区中都需要使用（与绑定到物理分区的RU / s相反）。这在Microsoft博客中特别提到，作为处理热分区键的一种方法。 更新：博文不再可用;也许是因为信息不准确。这是原始的博客文章：
答案 1 :(得分：0)
分区管理由Azure Cosmos DB完全管理，您无需编写复杂代码或管理分区。 Cosmos DB容器在存储和吞吐量方面无限制。我建议您阅读this以获取更多信息。
答案 2 :(得分：0)
不，只有在达到分区的存储限制时才会拆分分区（看起来是10GB）。
您可以验证将完整分区拆分为两个新分区吗？ 对于测试用例，我在所有分区中传播多个分区键值，并使用唯一的分区键值填充一个分区。与cosmos db metrics相关，此值占用大约5.1 GB的存储空间，并且物理分区已达到其10 GB存储限制。 如果我尝试添加具有相同partitionkey-value的更多文档，则我在VS中的c＃console应用程序会抛出ForbiddenException，其中显示“超出'Document'的存储配额”。“metrics视图还显示完整分区但是没有任何自动拆分这个完整的分区。 任何人都可以帮助我吗？