Hash vs string for objects in Redis - Visual Side-by-Side Comparison

Concept Flow - Hash vs string for objects

Start: Store object data

↓

String

↓

End

This flow shows how storing an object in Redis can use either a single string or a hash with fields, affecting how data is stored, retrieved, and updated.

Execution Sample

Redis

SET user:1 "name:John,age:30,city:NY"
HSET user:1 name John age 30 city NY
GET user:1
HGET user:1 name

Store a user object as a string and as a hash, then retrieve the whole string and a single field from the hash.

Execution Table

Step	Command	Action	Result
1	SET user:1 "name:John,age:30,city:NY"	Store entire object as one string	OK
2	HSET user:1 name John age 30 city NY	Store object fields separately in hash	3 (fields set)
3	GET user:1	Retrieve whole string value	"name:John,age:30,city:NY"
4	HGET user:1 name	Retrieve single field 'name' from hash	"John"
5	HGET user:1 age	Retrieve single field 'age' from hash	"30"
6	SET user:1 "name:Jane,age:31,city:LA"	Overwrite whole string with new data	OK
7	HSET user:1 city LA	Update only 'city' field in hash	1 (field updated)
8	GET user:1	Retrieve updated whole string	"name:Jane,age:31,city:LA"
9	HGET user:1 city	Retrieve updated 'city' field from hash	"LA"

💡 Commands complete; demonstrates differences in storing and updating objects as string vs hash.

Variable Tracker

Key	Start	After Step 1	After Step 2	After Step 6	After Step 7
user:1 (string)	null	"name:John,age:30,city:NY"	"name:John,age:30,city:NY"	"name:Jane,age:31,city:LA"	"name:Jane,age:31,city:LA"
user:1 (hash)	empty	{name: John, age: 30, city: NY}	{name: John, age: 30, city: NY}	{name: John, age: 30, city: NY}	{name: John, age: 30, city: LA}

Key Moments - 2 Insights

Why does updating a field in a hash not affect other fields?

Because each field in a hash is stored separately, updating one field only changes that field, unlike a string where the whole value must be overwritten (see steps 7 and 6 in execution_table).

Why do we need to parse the string to get individual fields?

The string stores all data as one text blob, so to get a single field like 'name', you must parse the string manually. Hashes store fields separately, so you can get them directly (see steps 3 vs 4).

Visual Quiz - 3 Questions

Look at the execution_table at step 4, what is the result of HGET user:1 name?

A "John"

B "name:John"

C "user:1"

D null

💡 Hint

Check the 'Result' column in execution_table row for step 4.

At which step does the string value for user:1 change to "name:Jane,age:31,city:LA"?

A Step 2

B Step 6

C Step 7

D Step 9

💡 Hint

Look at the 'Action' and 'Result' columns for the string key in execution_table.

If you want to update only the city field without affecting other data, which command is better?

A SET user:1 "new string"

B HSET user:1 city NewCity

C GET user:1

D DEL user:1

💡 Hint

Refer to steps 6 and 7 in execution_table to see how updates differ.

Concept Snapshot

Redis stores objects as either strings or hashes.
Strings hold the whole object as one text value.
Hashes store each field separately as key-value pairs.
Strings require full overwrite to update.
Hashes allow updating individual fields easily.
Use hashes for flexible field access and updates.

Full Transcript

This visual execution compares storing objects in Redis as strings versus hashes. First, the object is stored as a single string with all fields combined. Then, the same object is stored as a hash with separate fields. Retrieving the string returns the whole object text, while retrieving from the hash can get individual fields directly. Updating a string requires overwriting the entire value, but updating a hash can change just one field without affecting others. This shows the practical differences in how Redis handles these two data types for objects.