Cosmos DB Request Units & Partitioning – Complete Guide for DP-900
Why Is This Important?
Azure Cosmos DB is Microsoft's globally distributed, multi-model database service and a cornerstone topic on the DP-900 (Azure Data Fundamentals) exam. Two of the most critical concepts you must understand are Request Units (RUs) and Partitioning. These concepts govern how Cosmos DB handles performance, scalability, and cost. Without a solid grasp of RUs and partitioning, you will struggle with exam questions related to Cosmos DB provisioning, throughput, pricing, and data distribution.
What Are Request Units (RUs)?A
Request Unit (RU) is a normalized, blended measure of the computational cost required to perform database operations in Cosmos DB. Think of it as a single currency that abstracts away CPU, memory, and IOPS into one easy-to-understand number.
Key facts about Request Units:• A single point read (fetching one item by its ID and partition key) of a 1 KB document costs
1 RU.
• Writing, updating, deleting, and querying documents all consume RUs, but at different rates.
• More complex queries (those that scan multiple partitions, use aggregations, or process large documents) consume
more RUs.
• RUs are measured on a
per-second basis. When you provision throughput, you specify
RU/s (Request Units per second).
Provisioning Throughput:Cosmos DB offers two throughput provisioning modes:
1.
Provisioned Throughput – You manually set the number of RU/s. This is ideal for predictable workloads. You can provision throughput at the
database level (shared among all containers) or at the
container level (dedicated to a single container). The minimum is
400 RU/s per container (or database when shared).
2.
Serverless – You pay only for the RUs consumed by your operations. There is no upfront provisioning. This is ideal for development, testing, or workloads with unpredictable or intermittent traffic.
3.
Autoscale – Cosmos DB automatically scales the provisioned RU/s between a minimum (10% of the max) and a maximum value you set. This is ideal for workloads with variable but somewhat predictable traffic patterns.
How RUs Affect Cost:• You are billed based on the number of RU/s you provision (or consume in serverless mode) on an hourly basis.
• Over-provisioning wastes money; under-provisioning causes requests to be
rate-limited (HTTP 429 errors).
• The Azure portal provides metrics and recommendations to help you right-size your RU/s allocation.
What Is Partitioning in Cosmos DB?Partitioning is the mechanism Cosmos DB uses to
horizontally scale data across multiple physical servers. It is essential for achieving high performance and virtually unlimited storage.
Logical Partitions:• Every item in a Cosmos DB container has a
partition key — a property you define when creating the container.
• All items that share the same partition key value belong to the same
logical partition.
• A single logical partition can hold a maximum of
20 GB of data.
• Logical partitions are the fundamental unit of scope for transactions (stored procedures and triggers operate within a single logical partition).
Physical Partitions:• Cosmos DB automatically maps one or more logical partitions to
physical partitions.
• Physical partitions are the actual server resources (compute, storage, throughput) managed by Cosmos DB behind the scenes.
• Each physical partition can store up to
50 GB of data and handle up to
10,000 RU/s of throughput.
• You do
not manage physical partitions directly — Cosmos DB handles splitting and merging automatically.
Choosing a Good Partition Key:This is one of the
most important design decisions when using Cosmos DB. A good partition key should:
• Have a
high cardinality (many distinct values) — e.g.,
userId,
deviceId, or
tenantId.
• Distribute data
evenly across logical partitions to avoid
hot partitions (partitions that receive disproportionately more traffic or storage).
• Be used frequently in your queries'
WHERE clauses to enable efficient, single-partition queries.
Examples of good partition keys: /userId,
/tenantId,
/deviceIdExamples of poor partition keys: /country (low cardinality),
/createdDate (can create hot partitions for recent dates), a boolean field like
/isActive (only two values)
Cross-Partition vs. Single-Partition Queries:• A
single-partition query targets one logical partition (the partition key is included in the query filter). This is the
most efficient query type.
• A
cross-partition query (also called a fan-out query) must query multiple or all partitions. These consume
significantly more RUs and are less efficient.
How RUs and Partitioning Work Together• Provisioned RU/s are distributed
evenly across all physical partitions.
• If you provision 10,000 RU/s and have 5 physical partitions, each physical partition gets
2,000 RU/s.
• A
hot partition can become a bottleneck — even if you have unused RU/s on other partitions, the overloaded partition may get rate-limited.
• This is why choosing a partition key that distributes both
data and request volume evenly is critical.
Summary TableConcept →
Key DetailRequest Unit (RU) → Normalized cost of a database operation
1 RU → Point read of a 1 KB item by ID and partition key
Provisioned Throughput → Manual RU/s allocation (min 400 RU/s)
Autoscale → Automatic scaling between 10%-100% of max RU/s
Serverless → Pay per RU consumed, no provisioning
Logical Partition → Group of items sharing the same partition key value (max 20 GB)
Physical Partition → Server-managed storage unit (max 50 GB, 10,000 RU/s)
Partition Key → Property used to distribute data; must have high cardinality
Single-Partition Query → Most efficient; includes partition key in filter
Cross-Partition Query → Fan-out query; more expensive in RUs
Exam Tips: Answering Questions on Cosmos DB Request Units and Partitioning1.
Remember the RU baseline: A point read of a 1 KB document = 1 RU. Writes cost more than reads. Complex queries cost more than simple ones. If an exam question asks what consumes the fewest RUs, the answer is usually a point read by ID and partition key.
2.
Know the throughput modes: Be able to distinguish between
provisioned,
autoscale, and
serverless. Questions often present a scenario and ask which mode is most appropriate. Predictable workloads → provisioned. Variable workloads → autoscale. Dev/test or light workloads → serverless.
3.
Understand rate limiting: When consumed RU/s exceed provisioned RU/s, Cosmos DB returns
HTTP 429 (Too Many Requests). The solution is to increase provisioned throughput, use autoscale, or optimize queries to consume fewer RUs.
4.
Partition key selection questions are common: If the question asks for the best partition key, choose the option with the
highest cardinality that evenly distributes data. Avoid keys with very few distinct values.
5.
Remember the limits: Logical partition max =
20 GB. Physical partition max =
50 GB and
10,000 RU/s. Minimum provisioned throughput =
400 RU/s. These numbers are frequently tested.
6.
Single-partition queries are preferred: If a question asks about query efficiency or best practices, always favor queries that include the partition key in the filter.
7.
Shared vs. dedicated throughput: Know that throughput can be provisioned at the database level (shared across containers) or at the container level (dedicated). Questions may ask when to use each approach.
8.
RUs encompass everything: Do not confuse RUs with just CPU or just storage. RUs abstract CPU, memory, and IOPS into a single metric. If an exam question defines RUs, the correct answer will reference this blended/normalized concept.
9.
Hot partitions cause throttling: Even with sufficient total RU/s, an uneven distribution of requests can cause throttling on specific partitions. Look for answer choices that reference partition key design when a question describes throttling despite adequate total throughput.
10.
Watch for distractors: The exam may include options like DTUs (Database Transaction Units), which belong to
Azure SQL Database, not Cosmos DB. Always associate
RUs with Cosmos DB and
DTUs/vCores with Azure SQL.
By mastering Request Units and Partitioning, you will be well-prepared to answer a significant portion of the Cosmos DB questions on the DP-900 exam with confidence.
