Azure CosmosDB Pricing Intricacies

The Azure CosmosDB system has the potential to be a great storage layer for your solution. It automatically scales to maintain performances by splitting the data into partitions. It can geo-replicate in order to minimize data transfer latencies and has multiple consistency models to suit your different needs.

But…

In CosmosDB you pay for two things within a data center.
1 – The storage you use, which is a flat fee per gigabyte.
2 – The amount of RUs you would like to provision per second for performance. An RU is an arbitrary unit meaning roughly “something similar to reading 1k”.
If you replicate your dataset to another data center for redundancy or to reduce latency, these costs are PER data center.

Now for the trickiness, when you provision performance, let’s say 10k RU/sec, you are saying that you would like the entire dataset to be served with that performance level. Then arrives a more complicated subject: partitions. A partition is basically a split of your container into multiple parts that represent different sections of your data. For example, if your partition key is a person’s family name, you might end up with partitions for people’s last name starting with [A-G], [H-J], [K-Q], [R-Z]. In this scenario, 4 partitions whom must share equally the performance hence 2500 RU/sec per partition. Note that globally the performance level is the same, but if for a given amount of time, only one partition is solicited, then it will appear as if only 2500 RU/sec was available.

For small datasets that might not be so dramatic as partitions might never occur… but for larger datasets that can grow, CORRECTLY choosing a partition key becomes of paramount importance…

With this understanding, you might think that CosmosDB is great because you pay the same amount per month for a given performance. But two scenarios might arise…

1 – Partitions might exhaust their part of the total RU/sec faster than anticipated due to bad partition keys or specific usage patterns. Your usage of CosmosDB must be resilient to that fact that the system is unavailable because RU/sec have been exhausted.

2 – There is a minimum amount of RU/sec required to host a partition. If the container splits to a point where a partition has less than 100 RU/sec (current value), then RU/sec will be added to your bill in order to guarantee that minimum per partition.

Hope that clears a few things up !


 
Comments

No comments yet.