Embedding vs referencing in Redis - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Embedding in Redis

In Redis, embedding data means storing related information together in a single key. Which of the following best describes a scenario where embedding is beneficial?

A Storing large binary files separately and referencing them by file IDs.

B Storing user profiles in one key and their orders in separate keys linked by user IDs.

C Using separate keys for each product and referencing them in a shopping cart key.

D Storing user profile details and their recent activity logs together in one hash for quick access.

💡 Hint

Think about when you want to access all related data quickly without multiple lookups.

Embedding groups related data in one place, which is efficient when you often need all that data together. Option D shows this by combining profile and recent activity in one hash.

🧠 Conceptual

intermediate

When to Use Referencing in Redis

Referencing in Redis means storing related data separately and linking them by keys or IDs. Which situation is best suited for referencing?

A Storing product details separately and referencing them in multiple shopping carts.

B Storing a blog post and all its comments together in one hash.

C Storing all user data in one large JSON string.

D Embedding all order details inside the user profile hash.

💡 Hint

Consider when data is shared or reused in multiple places.

Referencing is ideal when data is reused or shared, like product details referenced by many shopping carts. This avoids duplication and keeps data consistent.

❓ query_result

advanced

Result of Embedded Data Retrieval

Given a Redis hash key 'user:1000' storing embedded data: {"name":"Alice", "age":"30", "city":"NY"}, what is the output of the command: HGETALL user:1000 ?

Redis

HGETALL user:1000

A ["user:1000", "Alice", "age", "30", "city", "NY"]

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

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

D Error: key does not exist

💡 Hint

HGETALL returns all fields and values as strings in an array.

HGETALL returns all fields and values in the hash as an array of strings. Option B matches the exact output format.

❓ query_result

advanced

Output of Referencing Data Retrieval

Assume you have two Redis keys: 'product:200' with value '{"name":"Book", "price":"15"}' and 'cart:300' storing a list of product IDs ['200', '201']. What is the output of LRANGE cart:300 0 -1 ?

Redis

LRANGE cart:300 0 -1

A Error: wrong type operation on string

B [{"name":"Book", "price":"15"}, {"name":"Pen", "price":"5"}]

C ["200", "201"]

D []

💡 Hint

LRANGE returns elements of a list as stored, not the referenced data.

LRANGE returns the list elements as strings. It does not fetch referenced data automatically. So it returns the product IDs stored in the list.

❓ schema

expert

Designing Redis Schema for Mixed Embedding and Referencing

You want to design a Redis schema for an e-commerce app where user profiles embed contact info but reference orders separately. Which schema design below correctly follows this approach?

A User profile stored as hash 'user:ID' with fields 'name', 'email', 'phone'; orders stored as separate lists 'orders:ID' containing order IDs.

B User profile stored as JSON string with embedded orders array inside; orders stored inside user hash fields.

C Orders stored as hashes with user IDs embedded inside; user profiles stored as separate keys with no contact info.

D All user data and orders embedded in one large hash 'user:ID' with nested fields for orders.

💡 Hint

Embedding contact info means storing it directly in user profile; referencing orders means separate keys.

Option A correctly embeds contact info in user hash and references orders separately by storing order IDs in separate lists. This balances embedding and referencing.

Practice

1. Which statement best describes embedding in Redis?

easy

A. Storing related data together in one key.

B. Storing data in separate keys linked by IDs.

C. Using multiple databases for related data.

D. Storing only references without actual data.

Solution

1. Step 1: Understand embedding concept

   Embedding means putting related data inside one Redis key, so all data is together.

2. Step 2: Compare with referencing

   Referencing stores data separately and links them by IDs, which is different from embedding.

3. Final Answer:

   Storing related data together in one key. -> Option A

4. Quick Check:

   Embedding = data together [OK]

Hint: Embedding means one key holds all related data [OK]

Common Mistakes:

• Confusing embedding with referencing
• Thinking embedding uses multiple keys
• Assuming embedding stores only IDs

2. Which Redis data structure is best suited for embedding small related data together?

easy

A. Sorted Set

B. String

C. List

D. Hash

Solution

1. Step 1: Identify data structure for embedding

   Hashes store multiple fields and values inside one key, ideal for embedding related small data.

2. Step 2: Compare other structures

   Strings hold single values, Lists and Sorted Sets are for ordered collections, less suited for embedding small related fields.

3. Final Answer:

   Hash -> Option D

4. Quick Check:

   Embedding small data = Hash [OK]

Hint: Use Hash for embedding small related fields [OK]

Common Mistakes:

• Choosing String for multiple fields
• Confusing List with Hash
• Using Sorted Set without score relevance

3. Given these Redis commands:

HSET user:100 name "Alice" age 30
HSET user:100:address city "NY" zip 10001

Which describes the data design?

medium

A. Referencing address data in a separate key

B. Embedding all user data in one key

C. Using a List to store user info

D. Storing user data as a String

Solution

1. Step 1: Analyze keys and data

   user:100 holds name and age, user:100:address holds address fields separately.

2. Step 2: Identify design pattern

   Address is stored in a separate key linked by user ID, which is referencing.

3. Final Answer:

   Referencing address data in a separate key -> Option A

4. Quick Check:

   Separate keys linked by ID = referencing [OK]

Hint: Separate keys with related IDs mean referencing [OK]

Common Mistakes:

• Thinking all data is embedded in one key
• Confusing List with Hash usage
• Assuming address is embedded inside user key

4. You want to store user profiles with embedded address data in Redis using hashes. Which command has an error?

medium

A. HSET user:200 name "Bob" age 25

B. HSET user:200:address city "LA" zip 90001

C. HSET user:200 name "Bob" city "LA" zip 90001

D. HSET user:200 name "Bob" age 25 city "LA" zip 90001

Solution

1. Step 1: Check embedding address in user hash

   Embedding means all fields in one key, so address fields city and zip should be in user:200 hash.

2. Step 2: Identify error in command C

   Command C uses a separate key user:200:address, storing address separately linked by ID. This is referencing, not embedding.

3. Final Answer:

   HSET user:200:address city "LA" zip 90001 -> Option B

4. Quick Check:

   Separate keys = referencing, not embedding [OK]

Hint: Embedding: all data in ONE key, no sub-keys [OK]

Common Mistakes:

• Missing value for a field
• Using separate keys when embedding
• Mixing field-value pairs incorrectly

5. You have a Redis database storing product info. You want to optimize for fast reads of product details including reviews. Which design is best?

hard

A. Embed product details and all reviews in one hash key per product.

B. Store all reviews in a single list key for all products.

C. Store product details in one hash and each review in separate keys linked by product ID.

D. Store product details as strings and reviews as sorted sets.

Solution

1. Step 1: Consider data size and access pattern

   Reviews can be many and large, embedding all in one key can cause large data and slow updates.

2. Step 2: Choose referencing for scalability

   Storing product details separately and reviews in linked keys allows efficient updates and reads without large keys.

3. Step 3: Evaluate other options

   Embedding all reviews in one hash risks large keys; storing all reviews in a single list key for all products mixes products; storing product details as strings and reviews as sorted sets don't fit review structure well.

4. Final Answer:

   Store product details in one hash and each review in separate keys linked by product ID. -> Option C

5. Quick Check:

   Large related data = referencing for performance [OK]

Hint: Large or many related items? Use referencing [OK]

Common Mistakes:

• Embedding large lists causing slow reads
• Mixing all reviews in one key
• Ignoring update frequency of reviews