📖 Scenario: You are building a simple Redis database to store information about books and their authors. You want to understand the difference between embedding author details directly inside the book data versus referencing the author data separately.
🎯 Goal: Create Redis data structures to store books and authors using both embedding and referencing methods. Learn how to organize data in Redis for these two approaches.
📋 What You'll Learn
Create a Redis hash for a book with embedded author details
Create a Redis hash for an author separately
Create a Redis hash for a book that references the author by ID
Add a key to link the book to the author ID
💡 Why This Matters
🌍 Real World
Many applications use Redis to store fast-access data like books and authors. Understanding embedding vs referencing helps design efficient data models.
💼 Career
Knowing how to organize data in Redis is useful for backend developers, database administrators, and anyone working with NoSQL databases.
Progress0 / 4 steps
1
Create a Redis hash for a book with embedded author details
Create a Redis hash with the key book:1 that stores the book's title as "Redis Basics" and embed the author's name as "Alice" and birth_year as "1980" inside the same hash.
Redis
Hint
Use the HSET command with the key book:1 and fields title, author_name, and author_birth_year.
2
Create a Redis hash for an author separately
Create a Redis hash with the key author:1 that stores the author's name as "Alice" and birth_year as "1980".
Redis
Hint
Use HSET with key author:1 and fields name and birth_year.
3
Create a Redis hash for a book that references the author by ID
Create a Redis hash with the key book:2 that stores the book's title as "Advanced Redis" and a field author_id with the value "1" to reference the author.
Redis
Hint
Use HSET with key book:2 and fields title and author_id.
4
Add a key to link the book to the author ID
Create a Redis string key book:2:author with the value "author:1" to link the book to the author record.
Redis
Hint
Use the SET command with key book:2:author and value author:1.
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
Step 1: Understand embedding concept
Embedding means putting related data inside one Redis key, so all data is together.
Step 2: Compare with referencing
Referencing stores data separately and links them by IDs, which is different from embedding.
Final Answer:
Storing related data together in one key. -> Option A
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
Step 1: Identify data structure for embedding
Hashes store multiple fields and values inside one key, ideal for embedding related small data.
Step 2: Compare other structures
Strings hold single values, Lists and Sorted Sets are for ordered collections, less suited for embedding small related fields.
Final Answer:
Hash -> Option D
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
Step 1: Analyze keys and data
user:100 holds name and age, user:100:address holds address fields separately.
Step 2: Identify design pattern
Address is stored in a separate key linked by user ID, which is referencing.
Final Answer:
Referencing address data in a separate key -> Option A
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
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.
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.
Final Answer:
HSET user:200:address city "LA" zip 90001 -> Option B
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
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.
Step 2: Choose referencing for scalability
Storing product details separately and reviews in linked keys allows efficient updates and reads without large keys.
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.
Final Answer:
Store product details in one hash and each review in separate keys linked by product ID. -> Option C
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 unknownstrongwhile earning +1 Grip toward your certificate.