*** Azure Cosmos DB partitioning is an important topic to learn.
Azure Cosmos DB uses partitioning to scale containers and meet demanding performance requirements. By dividing data into logical partitions based on a chosen partition key and mapping those to physical partitions, Cosmos DB ensures even distribution of throughput and storage.
This article breaks down the concepts, illustrates best practices, and provides tangible examples to help you design an efficient partitioning strategy.
What Is Partitioning?
Partitioning is dividing data into distinct segments to optimize storage, performance, and scalability.
Partitioning is divided into two types and each of them are interdependent.
👉 Logical Partitions
👉 Physical Partitions
Logical Partitions
A logical partition is a set of items sharing the same partition key value. When you define a partition key path (for example `/userId`), every item carrying that property value belongs to one logical partition.
Cosmos DB transparently creates new logical partitions as you insert items with new key values.
Each logical partition can grow up to 20 GB of storage, and transactions scoped to a single logical partition and support snapshot isolation.
Choosing a key with many distinct values prevents any single logical partition from hitting the size limit, ensuring smooth growth.
Example: In a food-nutrition container, using `/foodGroup` as the partition key groups items like “Beef Products” or “Vegetable Products” into separate logical partitions.
You need to do design the pattern that no single partition key cannot store more than 20GB of data.
Physical Partitions
Physical partitions are internal storage and throughput units managed by Cosmos DB. They host one or more logical partitions. Each physical partition supports up to 50 GB of data and 10,000 request units per second (RU/s).
As your container’s total RU/s or data size grows, Cosmos DB automatically splits physical partitions to maintain performance and availability. Even after a split, all items in a given logical partition remain on the same physical partition, only the mapping changes.
Example of throughput distribution: If you provision 18,000 RU/s across a container with three physical partitions, each partition receives 6,000 RU/s. Within one physical partition, multiple logical partitions (e.g., “Beef Products” and “Soups”) share that 6,000 RU/s budget.
Choosing the Right Partition Key
Selecting a partition key is the most impactful design decision for performance and cost. A good key should:
- Be immutable and present on every item
- Have high cardinality (many distinct values)
- Distribute read and write operations evenly
- Align with common query filters. Like normal querying on Customer ID, Product Id
Poor key choices can lead to hot partitions, inefficient RU usage, or frequent cross-partition queries, all of which increase latency and cost.
Types of Partition Key Strategy:
Handling Hot Partitions
A hot partition occurs when one logical partition receives disproportionate traffic. This can exhaust its RU/s share while other partitions remain under-utilized.
Example: In a server monitoring system, using `/metricType` alone might overload partitions during periods of elevated CPU or disk-I/O events. To prevent hot partitions, you can create a composite key such as `/metricType/eventTime`, which spreads entries by both metric and time interval.
Example: E-Commerce Orders Container
Consider an orders container in an online store:
- Partition key: `/customerId`
- Provisioned throughput: 30,000 RU/s
If Cosmos DB allocates 10,000 RU/s per physical partition, three partitions are needed. Each customer’s orders live in one logical partition. Point reads for a given `customerId` are efficient, using direct lookups.
To demonstrate data distribution:
| Physical Partition | Logical Partition Keys | RU/s Allocated |
|--------------------|-----------------------------------|----------------|
| P1 | CustA, CustB, CustC | 10,000 |
| P2 | CustD, CustE, CustF | 10,000 |
| P3 | CustG, CustH, CustI | 10,000 |
This design scales as new customers join—each new `customerId` yields a new logical partition that Cosmos DB assigns to an existing or new physical partition.
For more information on Partitioning, refer this Microsoft Documentation on Partitioning.
Read Next Topic:
Comments
Post a Comment