Chr*_*oli 4 orleans azure-cosmosdb azure-cosmosdb-sqlapi
我们最近开始测试 Cosmos DB 作为我们奥尔良集群的持久存储。
我们的 Cosmos DB 方案是作为具有低延迟和大量替换、点读取和创建的键值存储。因此,我们的文档 ID 和分区键是相同的,因此基本上每个分区 1 个文档。
但是,在 Cosmos DB Insights 中,我们看到我们达到了 100% 标准化 RU 消耗:
当我们深入挖掘时,我们会看到一个热图,它在 PartitionKeyRangeID 0 上放置了 100% RU 消耗,而没有其他 PartitionKeyRanges 可用。

我的理解是,由于我们有与文档一样多的分区,我们应该会遇到这个问题。我也不确定 PartitionKeyRangeID 0 表示什么,因为我们应该至少有几千个分区
PartitionKeyRangeID 对应物理分区。
在这种情况下,您似乎只有一个物理分区,并且已达到最大值。
每个物理分区每秒最多支持 10k RU,因此如果您将集合扩展到强制拆分之上(或者如果每个分区的存储容量限制需要拆分),您将看到额外的物理分区。
您的逻辑分区键被散列,并且散列空间被划分为跨物理分区分配的范围。
来自预配置吞吐量的 RU 预算在物理分区之间分配。当您有多个物理分区时,热图很有用,因此您可以识别某些物理分区已用完而其他物理分区空闲的情况(这可能是由于热逻辑分区造成的)。
| 归档时间: |
|
| 查看次数: |
56 次 |
| 最近记录: |