Access patterns & denormalization
Access patterns & denormalization
Bronze
In a NoSQL store you design the data from the questions the app will ask, not from the entities alone. First list the access patterns — "the latest 50 messages in a group", "this member's balance" — then choose keys so each one is a single, cheap lookup. The partition key decides which items are stored together; the sort key keeps them in order inside that partition, so "the latest N" or "this month's" is one range read. Data read together is stored together, even if that means copying it — denormalization. Copies make reads cheap and writes expensive — every change must reach every copy, and each copy takes storage — so normalize what changes often and copy what is read often.
- Use when
- A few access patterns carry most of the traffic and are known up front · Reads far outnumber writes, and joining at read time is the bottleneck · The data is too large or too busy for one relational database, and you are moving to a key-based store
- Avoid when
- The questions are still changing — a normalized relational model adapts more easily · The copied data changes often and is shared by many items — every change fans out to all copies · One partition would grow without limit — add a time bucket or another key part first
- Trade-offs
- Copies make reads one lookup, at the price of extra writes and storage on every change · Keys tuned to today's queries make a new kind of query expensive until you add an index or a new copy · A secondary index is a convenient automatic copy — and it lags behind the table and costs writes too
- Requires
- NoSQL families
3 objectives · 5 misconceptions
- choose Choose a partition key and sort key that turn each listed access pattern into a single lookup or range read.
- predict Predict how many writes and how much extra storage a denormalized design costs when one shared fact changes.
- choose Choose whether to embed related data, copy part of it, or keep a reference, from how often it is read, how often it changes and whether it grows without bound.
- Not true: Model the entities first, the way you would in a relational database, and work out the queries later.
- Not true: Duplicating data is free — storage is cheap and the copies stay in sync by themselves.
- Not true: Every kind of entity needs its own table.
- Not true: It's fine to keep all of one group's messages in a single partition forever.
- Not true: Denormalizing is always better, so a NoSQL design should copy everything everywhere.
Learn
Access patterns & denormalizationMembers~13 minPractice
No katas practice this yet.