We have recently started testing Cosmos DB as a persistent storage for our Orleans Cluster.
Our scenario for Cosmos DB is as a Key-Value Store with low-latency and a high amount of Replace, Point Reads and Creates. Due to this we have Document IDs and Partition Keys be the same, so essentially 1 document per partition.
However, in the Cosmos DB Insights we are seeing that we are reaching 100% Normalized RU Consumption:
When we dig deeper we see a heat map that puts 100% RU Consumption on PartitionKeyRangeID 0 with no other PartitionKeyRanges available.
It is my understanding that since we have as much partitions as we have documents, we should be reaching this problem. I am also not sure what PartitionKeyRangeID 0 signifies as we should have at least quite a few thousand partitions
PartitionKeyRangeID corresponds to physical partition.
Your logical partition key is hashed and the hash space is divided up into ranges that are allocated to each physical partition. For example in a collection with two partitions Partition 1 might take the range from 0x00000000000000 to 0x7FFFFFFFFFFFFF and Partition 2 the range from 0x80000000000000 to 0xFFFFFFFFFFFFFF.
In this case it looks like you have a single physical partition and this is maxed out.
Each physical partition supports up to 10k RU per sec so you would see additional physical partitions if you were to scale the collection above that forcing a split (or if a split is required for per partition storage capacity limits).
The RU budget from your provisioned throughput is divided between the physical partitions. The heat map is useful when you have multiple physical partitions so you can identify cases where some physical partitions are maxed out and others are idle (which would be likely due to hot logical partitions).