Denormalization for speed in Redis - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to set a user's name in Redis.

Redis

redis.call('SET', 'user:[1]:name', 'Alice')

Drag options to blanks, or click blank then click option'

Aname

B123

Cuser

Dprofile

Attempts:

3 left

💡 Hint

Common Mistakes

Using generic words like 'user' or 'name' without an ID causes key collisions.

The key should include the user ID to uniquely identify the user's name.

2fill in blank

medium

Complete the code to retrieve the user's email from Redis.

Redis

local email = redis.call('GET', 'user:[1]:email')

Drag options to blanks, or click blank then click option'

Auser

Bprofile

Cemail

D456

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'email' or 'user' as the ID part of the key instead of the actual user ID.

The key must include the user ID to get the correct email.

3fill in blank

hard

Fix the error in the code to increment the user's login count.

Redis

redis.call('[1]', 'user:789:login_count')

Drag options to blanks, or click blank then click option'

AINCR

BSET

CGET

DDEL

Attempts:

3 left

💡 Hint

Common Mistakes

Using SET replaces the value instead of incrementing it.

Using GET only reads the value without changing it.

INCR increases the integer value stored at the key by one, perfect for counting logins.

4fill in blank

hard

Fill both blanks to store a user's profile with denormalized data.

Redis

redis.call('[1]', 'user:[2]', 'name', 'Bob', 'email', '[e-mail]')

Drag options to blanks, or click blank then click option'

AHMSET

BSET

C101

Duser

Attempts:

3 left

💡 Hint

Common Mistakes

Using SET only stores a single string, not multiple fields.

Using a generic key like 'user' without an ID causes data overwrite.

HMSET sets multiple fields in a hash, and the key includes the user ID 101.

5fill in blank

hard

Fill all three blanks to create a denormalized Redis key for fast access.

Redis

redis.call('[1]', 'order:[2]:[3]', 'status', 'shipped')

Drag options to blanks, or click blank then click option'

AHMSET

B789

Cuser123

DSET

Attempts:

3 left

💡 Hint

Common Mistakes

Using SET stores only a string, not multiple fields.

Missing user ID in the key reduces denormalization benefits.

HMSET stores multiple fields, the order ID is 789, and user123 identifies the user for denormalization.

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