Denormalization for speed in Redis - Step-by-Step Execution

Concept Flow - Denormalization for speed

Start with normalized data

↓

Identify frequent joins/queries

↓

Duplicate related data into one record

↓

Store denormalized data in Redis

↓

Query single denormalized record

↓

Faster read, less joins

↓

Update duplicated data carefully

Denormalization copies related data into one place to speed up reads by avoiding joins, especially in Redis where data is stored as key-value pairs.

Execution Sample

Redis

HMSET user:1 id 1 name "Alice" age 30
HMSET order:101 id 101 user_id 1 total 50
// denormalized record
HMSET user_order:101 id 101 user_id 1 user_name "Alice" total 50
HGETALL user_order:101

Shows storing user and order separately, then a denormalized combined record for faster access.

Execution Table

Step	Action	Data Stored	Reason
1	Store user data	user:1 -> {id:1, name:"Alice", age:30}	Normalized user info
2	Store order data	order:101 -> {id:101, user_id:1, total:50}	Normalized order info
3	Create denormalized record	user_order:101 -> {id:101, user_id:1, user_name:"Alice", total:50}	Combine user and order for fast read
4	Query user_order:101	{id:101, user_id:1, user_name:"Alice", total:50}	Single read, no join needed
5	Update user name	Update user:1 and user_order:101	Must update duplicated data to keep consistency
6	Query user_order:101 again	{id:101, user_id:1, user_name:"Alice", total:50}	Fast read with updated data
7	End	-	Denormalization speeds up reads but requires careful updates

💡 Denormalization stops when data is combined for fast reads, but updates must keep duplicates consistent

Variable Tracker

Key	Initial	After Step 1	After Step 2	After Step 3	After Step 5	Final
user:1	none	{id:1, name:"Alice", age:30}	{id:1, name:"Alice", age:30}	{id:1, name:"Alice", age:30}	{id:1, name:"Alice", age:30}	{id:1, name:"Alice", age:30}
order:101	none	none	{id:101, user_id:1, total:50}	{id:101, user_id:1, total:50}	{id:101, user_id:1, total:50}	{id:101, user_id:1, total:50}
user_order:101	none	none	none	{id:101, user_id:1, user_name:"Alice", total:50}	{id:101, user_id:1, user_name:"Alice", total:50}	{id:101, user_id:1, user_name:"Alice", total:50}

Key Moments - 3 Insights

Why do we store the user name twice in both user:1 and user_order:101?

Because denormalization duplicates data to avoid joins during reads, so user_order:101 has user_name for faster access (see execution_table step 3).

What happens if we update user:1 but forget to update user_order:101?

The denormalized data becomes inconsistent, causing stale reads from user_order:101 (see execution_table step 5).

Why is querying user_order:101 faster than joining user:1 and order:101?

Because all needed data is in one record, so Redis fetches one key instead of multiple keys and combining them (see execution_table step 4).

Visual Quiz - 3 Questions

Look at the execution_table at step 3, what data is stored in user_order:101?

A {id:101, user_id:1, total:50}

B {id:101, user_id:1, user_name:"Alice", total:50}

C {id:1, name:"Alice", age:30}

D None

💡 Hint

Check the 'Data Stored' column in execution_table row for step 3

At which step does the denormalized record get updated after a user name change?

A Step 5

B Step 3

C Step 2

D Step 6

💡 Hint

Look for the step mentioning update of duplicated data in execution_table

If we remove the denormalized record user_order:101, what happens to read speed?

A It becomes faster

B It stays the same

C It becomes slower due to multiple reads

D It causes errors

💡 Hint

Denormalization avoids multiple reads by combining data, see concept_flow and execution_table

Concept Snapshot

Denormalization stores duplicated related data together to speed up reads.
In Redis, this means combining user and order info into one key.
This avoids multiple lookups and joins.
Updates must keep duplicated data consistent.
Denormalization trades write complexity for read speed.

Full Transcript

Denormalization for speed means copying related data into one place to avoid multiple lookups. In Redis, we store user data and order data separately, then create a combined denormalized record with user and order info together. This lets us read all needed data with one key fetch, making reads faster. However, when user data changes, we must update the denormalized record too to keep data consistent. The execution steps show storing user and order, creating the denormalized record, reading it fast, updating duplicates, and reading again. This method improves read speed but requires careful updates.

Practice

1. What is the main benefit of denormalization in Redis?

easy

A. Faster data retrieval by storing related data together

B. Reducing memory usage by splitting data into many keys

C. Ensuring data is always normalized for consistency

D. Automatically backing up data to disk

Solution

1. Step 1: Understand denormalization purpose

   Denormalization means storing related data together to avoid multiple lookups.

2. Step 2: Identify main benefit in Redis context

   This reduces the number of Redis calls, making data retrieval faster.

3. Final Answer:

   Faster data retrieval by storing related data together -> Option A

4. Quick Check:

   Denormalization = Faster access [OK]

Hint: Denormalization means fewer lookups, so speed improves [OK]

Common Mistakes:

• Confusing denormalization with normalization
• Thinking it reduces memory usage
• Assuming it automatically backs up data

2. Which Redis data structure is best suited for denormalization to store related user info together?

easy

A. Hash

B. List

C. Set

D. Sorted Set

Solution

1. Step 1: Review Redis data structures

   Lists store ordered values, Sets store unique unordered values, Sorted Sets store ordered unique values, Hashes store field-value pairs.

2. Step 2: Choose structure for related fields

   Hashes allow storing multiple fields (like name, email) under one key, ideal for denormalized user info.

3. Final Answer:

   Hash -> Option A

4. Quick Check:

   Hash = field-value pairs for related data [OK]

Hint: Use Hash for grouped related fields in one key [OK]

Common Mistakes:

• Choosing List which is just ordered values
• Using Set which stores unique values without fields
• Picking Sorted Set which is for ordered unique elements

3. Given these Redis commands for denormalized user data:

HSET user:1000 name "Alice" age 30 city "NY"

What does HGETALL user:1000 return?

medium

A. ["name", "Alice", "age", "30"]

B. ["name", "Alice", "age", "30", "city", "NY"]

C. ["name", "Alice", "age", 30, "city", "NY"]

D. ["user:1000", "Alice", "30", "NY"]

Solution

1. Step 1: Understand HSET command

   HSET stores fields and values under key 'user:1000' as strings: name=Alice, age=30, city=NY.

2. Step 2: Understand HGETALL output format

   HGETALL returns an array of field-value pairs as strings in order stored.

3. Final Answer:

   ["name", "Alice", "age", "30", "city", "NY"] -> Option B

4. Quick Check:

   HGETALL returns all fields and values as strings [OK]

Hint: HGETALL returns flat list of field-value strings [OK]

Common Mistakes:

• Expecting numeric types instead of strings
• Confusing key name with fields
• Partial field-value pairs returned

4. You try to denormalize user data with:

HSET user:2000 name "Bob" age 25 city "LA"

But later HGET user:2000 age returns nil. What is the likely cause?

medium

A. HSET command was not executed properly

B. The field name is misspelled in HGET

C. The age field was overwritten or deleted

D. The key user:2000 does not exist

Solution

1. Step 1: Check if key exists

   If key did not exist, all fields would be missing, but only age is missing.

2. Step 2: Consider field deletion or overwrite

   Age field might have been deleted or overwritten after initial HSET, causing nil return.

3. Final Answer:

   The age field was overwritten or deleted -> Option C

4. Quick Check:

   Missing field means deleted or overwritten [OK]

Hint: Missing field usually means it was deleted or overwritten [OK]

Common Mistakes:

• Assuming key does not exist when other fields exist
• Misspelling field name in HGET
• Thinking HSET failed without error

5. You want to speed up a Redis app by denormalizing product and category data. Which approach is best?

hard

A. Use a sorted set for categories and a list for products

B. Store product and category in separate keys and join at runtime

C. Normalize data fully to avoid duplication

D. Store product info and category name together in one hash key per product

Solution

1. Step 1: Understand denormalization goal

   Denormalization stores related data together to reduce lookups and speed access.

2. Step 2: Evaluate options for product-category data

   Storing product info and category name together in one hash avoids extra lookups, speeding queries.

3. Step 3: Compare other options

   Separate keys require joins (slower), sorted sets/lists don't group related fields, full normalization slows access.

4. Final Answer:

   Store product info and category name together in one hash key per product -> Option D

5. Quick Check:

   Denormalize related data together for speed [OK]

Hint: Put related data in one hash to avoid joins [OK]

Common Mistakes:

• Keeping data normalized causing slow joins
• Using sorted sets/lists without grouping fields
• Duplicating data without grouping properly