What's changed: Created DP-420 Chapter 1 (Domain 1 first-half: non-relational modeling (embed vs reference/denormalize/id-partition key-unique keys/default TTL/versioning); partition design (key choice/hot partition-429/cross-partition cost/data-throughput distribution/synthetic key/hierarchical key/single-logical-partition transactions); sizing and scaling (RU/s/serverless vs provisioned vs free/autoscale/database-level throughput/global-distribution cost)).
1.2Partition design
Understand choosing a partition key, workload-based strategy, cross-partition query cost, evaluating data/throughput distribution, and synthetic and hierarchical partition keys.
Cosmos DB scales horizontally by splitting data into logical partitions. Choosing the partition key is the most critical design decision for scalability and performance—and it cannot be changed once set.
1.2.1Choosing the key and evaluating distribution
A good partition key has high cardinality (many distinct values) and evens out both data distribution and request (throughput) distribution. Concentrated access to one value creates a hot partition (skewed RU/storage) and causes 429s. Choose a key by looking at "which queries are frequent" and "what filters them," favoring values that avoid cross-partition queries (fan-out across all partitions, higher RU cost). Because transactions (Transactional Batch, stored procedures) are limited to a single logical partition, transaction boundaries also influence key choice.
1.2.2Synthetic and hierarchical partition keys
When a single field skews distribution, use a synthetic partition key concatenating fields (e.g., tenantId-date) or a random suffix to raise cardinality. For workloads needing multiple levels (e.g., tenant→user→session), use a hierarchical partition key (up to three levels) to scale beyond the 20 GB per-logical-partition limit while enabling efficient queries on a leading prefix. For "single key skews / hits the limit," consider synthetic or hierarchical.
Cues: "high cardinality evening data + throughput" = good key. "concentration on one value" = hot partition/429. "fan-out = more RU" = cross-partition query. "single skews → concatenate/suffix" = synthetic key. "multi-level + beyond 20 GB" = hierarchical key. Transactions only within one logical partition.
Watch the mix-ups: (1) The partition key is immutable after creation—reworking it needs recreate/migration. (2) Synthetic keys (raise cardinality) vs hierarchical keys (multi-level, beyond 20 GB) differ in purpose. (3) Cross-partition queries are possible but cost more RU—minimize by design. (4) Mind the 20 GB per-logical-partition limit.
1.2.3Section summary
- Good key = high cardinality evening data/throughput; avoid hot partitions and 429s
- Cross-partition queries cost more RU—choose a key that frequent queries can filter on
- Synthetic key = raise cardinality; hierarchical key = multi-level scaling beyond 20 GB
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Access concentrates on one partition key value, skewing RU and causing frequent 429s. Best remedy?
Q2. A single field has low cardinality and skews. Which improves distribution?
Q3. Multi-tenant, you want to partition by tenant→user→session and scale beyond the 20 GB logical-partition limit. Best?
Q4. Which is correct about cross-partition queries?
Q5. What is the scope in which Cosmos DB transactions (Transactional Batch, stored procedures) operate?