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?