Embedding vs referencing in Redis - Visual Side-by-Side Comparison

Concept Flow - Embedding vs referencing

Start: Need to store related data

↓

Embed data

↓

Store all

↓

inside one

↓

record

↓

Fast read

↓

Use case depends on needs

↓

End

This flow shows the choice between embedding related data inside one record or referencing it by storing IDs separately, highlighting trade-offs.

Execution Sample

Redis

HMSET user:1 name "Alice" age 30
HMSET user:1:address city "NY" zip "10001"
HGETALL user:1
HGETALL user:1:address

Stores user data and address separately (referencing), then retrieves both.

Execution Table

Step	Command	Action	Data Stored/Retrieved	Notes
1	HMSET user:1 name "Alice" age 30	Store user basic info	{"name":"Alice","age":"30"}	User hash created
2	HMSET user:1:address city "NY" zip "10001"	Store address separately	{"city":"NY","zip":"10001"}	Address hash created separately
3	HGETALL user:1	Retrieve user info	{"name":"Alice","age":"30"}	User data fetched
4	HGETALL user:1:address	Retrieve address info	{"city":"NY","zip":"10001"}	Address data fetched
5	-	-	-	Execution ends after retrieval

💡 All commands executed; data stored and retrieved as separate hashes (referencing).

Variable Tracker

Key	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
user:1	none	{"name":"Alice","age":"30"}	{"name":"Alice","age":"30"}	{"name":"Alice","age":"30"}	{"name":"Alice","age":"30"}	{"name":"Alice","age":"30"}
user:1:address	none	none	{"city":"NY","zip":"10001"}	{"city":"NY","zip":"10001"}	{"city":"NY","zip":"10001"}	{"city":"NY","zip":"10001"}

Key Moments - 2 Insights

Why do we store address in a separate key instead of inside user:1?

Storing address separately (referencing) allows updating address without changing user data. See execution_table rows 2 and 4 where address is stored and retrieved separately.

What happens if we embed address inside user:1?

Embedding means all data is in one key, so retrieval is faster but updating address requires rewriting the whole user record. This contrasts with referencing shown in execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what data does the command at Step 3 retrieve?

A User's name and age

B User's address

C Both user info and address

D Nothing, it stores data

💡 Hint

Check the 'Data Stored/Retrieved' column at Step 3 in execution_table.

At which step is the address data stored separately?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the 'Action' column in execution_table for storing address.

If we embed address inside user:1, how would variable_tracker change?

A user:1 would be empty

B user:1 would include address fields after Step 1

C user:1:address would still be separate

D user:1:address would contain user info

💡 Hint

Embedding means all data is stored in one key; see variable_tracker for keys and their data.

Concept Snapshot

Embedding vs Referencing in Redis:
- Embedding: store all related data in one key (hash).
- Referencing: store related data in separate keys, link by IDs.
- Embedding is faster for reads, less flexible for updates.
- Referencing allows independent updates, more flexible.
- Choose based on update frequency and data size.

Full Transcript

This visual execution shows how Redis stores related data using embedding or referencing. Embedding means putting all data in one key, making reads fast but updates harder. Referencing stores related data in separate keys, linked by IDs, allowing flexible updates. The example stores user info and address separately, showing commands and data changes step-by-step. Key moments clarify why separate keys help updates. The quiz tests understanding of data retrieval and storage steps.

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