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.1Non-relational data modeling
Understand non-relational modeling in Azure Cosmos DB for NoSQL: embedding vs referencing, denormalization, multiple entity types in one container, id/partition key/unique keys, default TTL, and versioning.
Azure Cosmos DB for NoSQL is a non-relational database storing JSON documents. Unlike relational normalization, you design the model starting from access patterns (how it is read). The core idea: "store together what you read together."
1.1.1Embedding, referencing, and denormalization
With embedding, related entities live in one document, retrievable in a single read (good for 1:1 or 1:few, read together, low update frequency). With referencing, they are separate documents joined by id (good for 1:many, independently updated, large size). Denormalization duplicates data to speed reads, accepting redundancy. Cosmos DB often stores multiple entity types in one container (distinguished by a type field), shaped to the read pattern.
1.1.2id, keys, TTL, and versioning
Each item is uniquely identified by id and partition key (id is unique within a partition). A unique key enforces uniqueness of a field within a partition. Setting a default TTL (Time to Live) on a container auto-deletes old items, managing data lifetime in the transactional store (per-item TTL can override). Being schemaless, design document/schema versioning (a version field or schema evolution) to keep apps backward-compatible.
Cues: "read together, low update, 1:few" = embed. "independent updates, 1:many, large" = reference. "duplicate to speed reads" = denormalize. "auto-delete old items" = default TTL. enforce uniqueness = unique key (within a partition).
Watch the trade-offs: (1) Embedding (fast but update cost/size) vs referencing (flexible but multiple reads). (2) Consistency of denormalized copies must be maintained separately (e.g., Change Feed). (3) Unique keys are per-partition and immutable after container creation. (4) TTL applies to the transactional store, separate from analytical-store retention.
1.1.3Section summary
- Design from access patterns = embed (read together) vs reference (independent updates); denormalize to speed reads
- Items unique by id + partition key; unique keys enforce uniqueness within a partition
- Default TTL auto-deletes old items; design versioning because it is schemaless
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Orders and their few line items are always read together and rarely updated. Best modeling in Cosmos DB for NoSQL?
Q2. A customer has many independently updated orders. Best modeling?
Q3. You want to auto-delete old items in the transactional store after a period. Best?
Q4. You want a field’s values to be non-duplicated within a partition. Best?
Q5. What is a common way to keep denormalized duplicated data consistent?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.