8

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:

Normalized RU Consumption (max)

When we dig deeper we see a heat map that puts 100% RU Consumption on PartitionKeyRangeID 0 with no other PartitionKeyRanges available. enter image description here

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

Christopher Demicoli
  • 339
  • 1
  • 3
  • 10

1 Answers1

11

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).

Martin Smith
  • 438,706
  • 87
  • 741
  • 845
  • Thanks for your response. I have all keys in separate Partition Keys (since I'm using it as a KV Store). This is why I'm not understanding why it's always putting all the partitions on the same physical server – Christopher Demicoli Aug 24 '21 at 15:43
  • Because you only have one physical partition. A physical partition represents a certain amount of physical storage and compute capacity. You won't be allocated a new **physical** partition for every individual partition key. You will get a new physical partition if this is needed because you exceed the storage capacity or throughput capacity that a single physical partition can provide. – Martin Smith Aug 24 '21 at 15:48
  • In your case you have simply provisioned inadequate RU for your workload. The number of physical partitions (1) is not relevant to this. Once you are on more than one physical partition you may encounter additional issues around hot partitions but at the moment you only have one so this is simple – Martin Smith Aug 24 '21 at 15:51