Bird
Raised Fist0
Redisquery~10 mins

Embedding vs referencing in Redis - Interactive Practice

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to store a user profile with embedded address data in Redis using a hash.

Redis
HSET user:1000 name "Alice" [1] "123 Main St" city "Springfield"
Drag options to blanks, or click blank then click option'
Astreet
Baddress
Clocation
Daddr
Attempts:
3 left
💡 Hint
Common Mistakes
Using a generic term like 'address' which might be confusing in a hash.
Using abbreviations that are unclear.
2fill in blank
medium

Complete the code to reference an address stored separately by its ID in Redis.

Redis
HSET user:1001 name "Bob" address_id [1]
Drag options to blanks, or click blank then click option'
Aaddress:200
Baddr200
Caddress_200
Daddr:200
Attempts:
3 left
💡 Hint
Common Mistakes
Using keys without colon separators which is less common in Redis.
Using inconsistent naming conventions.
3fill in blank
hard

Fix the error in the code that tries to embed a list of phone numbers directly in a Redis hash.

Redis
HSET user:1002 name "Carol" phones [1]
Drag options to blanks, or click blank then click option'
A"[123-4567, 234-5678]"
B"123-4567;234-5678"
C"123-4567,234-5678"
D"123-4567 234-5678"
Attempts:
3 left
💡 Hint
Common Mistakes
Using JSON-like arrays which Redis hashes do not support.
Using semicolons or spaces which are less standard separators.
4fill in blank
hard

Fill in the blank to create a Redis command that retrieves the city from the referenced address hash.

Redis
HGET [1] city
Drag options to blanks, or click blank then click option'
Aaddress_300
Baddress:300
Cuser:city
Duser:300
Attempts:
3 left
💡 Hint
Common Mistakes
Using the user key instead of the address key.
Using underscores instead of colons in keys.
5fill in blank
hard

Fill all three blanks to create a Redis Lua script snippet that fetches a user name, then fetches the city from the referenced address hash.

Redis
local userKey = [1]
local addressKey = redis.call('HGET', userKey, [2])
return redis.call('HGET', addressKey, [3])
Drag options to blanks, or click blank then click option'
A'user:400'
B'address_id'
C'city'
D'name'
Attempts:
3 left
💡 Hint
Common Mistakes
Using wrong field names like 'name' instead of 'address_id' for the reference.
Mixing up the order of commands.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard