Azure Cosmos DB: How to Do Partition Merge?

Need a bit of guidance from someone who has executed, monitored, and confirmed the effectiveness of partition merge even after going through the official doc on partition merge? You have come to the right place.

Note: The term “partition” from here onward refers to physical partitions, unless stated otherwise. If you do not know the difference between physical and logical partitions yet, read this first.

In this piece, you will understand my environment before partition merge, how I executed partition merge, and further, how I verified that the partition merge was indeed effective in reducing number of partitions.

For reasons why one would be so keen to reduce the number of partitions, I plan to visit that in a separate article.

Disclaimer

For the purpose of this article, I did not use an environment which simulates typical production-level workloads. Nevertheless, this should serve as an excellent baseline.

Depending on my availability/demand, I may write a follow-up article on executing partition merge on tougher conditions which simulate a “typical” production workload, say 30+ physical partitions, presence of hot partitions, requests actively hitting the database, etc.

Let’s now get into the environment I had synthesized before executing the partition merge.

My Environment

Photo by Chase Baker on Unsplash

For starters, I created a NoSQL API Cosmos DB account called “al-nosql-db-r1”. At the time of writing this, there are only two officially supported APIs for partition merge according to the official documentation for partition merge:

• NoSQL API
• MongoDB API

I created a database called “pmdb” and a container under it called “pmcon1” with dedicated, manual provisioned throughput of 11,000 RU/s.