RDB snapshots (point-in-time) in Redis - Time & Space Complexity

Time Complexity: RDB snapshots (point-in-time)

O(n)

Understanding Time Complexity

We want to understand how the time to create a Redis RDB snapshot changes as the database grows.

Specifically, how does saving a point-in-time snapshot scale with the amount of data?

Scenario Under Consideration

Analyze the time complexity of this Redis snapshot command.

SAVE
    

This command creates a point-in-time snapshot of the entire Redis dataset by writing it to disk.

Identify Repeating Operations

What repeats during the snapshot process?

• Primary operation: Iterating over all keys and their values to write them to the snapshot file.
• How many times: Once for each key in the database.

How Execution Grows With Input

As the number of keys grows, the time to save grows too.

Input Size (n)	Approx. Operations
10	10 key writes
100	100 key writes
1000	1000 key writes

Pattern observation: The time grows roughly in direct proportion to the number of keys.

Final Time Complexity

Time Complexity: O(n)

This means the time to create a snapshot grows linearly with the number of keys in the database.

Common Mistake

[X] Wrong: "Saving a snapshot is instant no matter how much data there is."

[OK] Correct: The snapshot process must visit every key to save it, so more data means more work and more time.

Interview Connect

Understanding how snapshot time grows helps you reason about system performance and data durability in real projects.

Self-Check

"What if Redis used incremental snapshots instead of full snapshots? How would the time complexity change?"

Practice

1. What is the primary purpose of an RDB snapshot in Redis?

easy

A. To increase the speed of Redis commands

B. To save the current state of the database at a specific point in time

C. To permanently delete all data from Redis

D. To replicate data to another Redis instance in real-time

Solution

1. Step 1: Understand what RDB snapshots do

   RDB snapshots capture the exact data stored in Redis at a certain moment, creating a backup file.

2. Step 2: Compare options with snapshot purpose

   Only To save the current state of the database at a specific point in time describes saving the database state at a point in time, which matches the snapshot function.

3. Final Answer:

   To save the current state of the database at a specific point in time -> Option B

4. Quick Check:

   RDB snapshot = point-in-time save [OK]

Hint: Snapshots save data state at one moment, like a photo [OK]

Common Mistakes:

• Confusing snapshots with real-time replication
• Thinking snapshots delete data
• Assuming snapshots speed up commands

2. Which Redis command creates an RDB snapshot immediately and blocks the server until done?

easy

A. SAVE

B. BGSAVE

C. RESTORE

D. FLUSHDB

Solution

1. Step 1: Recall Redis commands for snapshots

   SAVE blocks Redis and saves the snapshot immediately; BGSAVE saves in background without blocking.

2. Step 2: Match command to blocking immediate save

   Only SAVE matches the description of immediate blocking snapshot creation.

3. Final Answer:

   SAVE -> Option A

4. Quick Check:

   Immediate blocking snapshot = SAVE [OK]

Hint: SAVE blocks Redis to save snapshot immediately [OK]

Common Mistakes:

• Choosing BGSAVE which is non-blocking
• Confusing RESTORE with saving snapshots
• Thinking FLUSHDB saves data

3. Given the following Redis commands executed in order:

BGSAVE
SET key1 value1
SAVE
SET key2 value2

Which keys will be present in the RDB snapshot created by the SAVE command?

medium

A. Neither key1 nor key2

B. Only key2

C. Only key1

D. Both key1 and key2

Solution

1. Step 1: Understand timing of BGSAVE and SAVE

   BGSAVE starts background save but does not block; SET key1 happens after BGSAVE starts, so key1 may or may not be in that snapshot.

2. Step 2: SAVE blocks and saves immediately after SET key1

   SAVE runs after SET key1 but before SET key2, so the snapshot from SAVE includes key1 but not key2.

3. Final Answer:

   Only key1 -> Option C

4. Quick Check:

   SAVE snapshot = keys before SAVE command [OK]

Hint: SAVE snapshot includes keys set before it runs [OK]

Common Mistakes:

• Assuming BGSAVE snapshot includes key1 for sure
• Thinking SAVE snapshot includes key2 set after it
• Confusing background and immediate saves

4. You run the command BGSAVE but receive an error: "Background save already in progress". What is the best way to fix this?

medium

A. Run FLUSHALL to clear all data and then run BGSAVE

B. Restart the Redis server to clear the background save

C. Run SAVE instead to block and save immediately

D. Wait for the current background save to finish before running BGSAVE again

Solution

1. Step 1: Understand the error cause

   The error means a background save is already running; Redis does not allow multiple concurrent BGSAVE commands.

2. Step 2: Choose the proper fix

   Waiting for the current BGSAVE to finish is the correct approach; running SAVE blocks but is not necessary, restarting or flushing data is extreme and unnecessary.

3. Final Answer:

   Wait for the current background save to finish before running BGSAVE again -> Option D

4. Quick Check:

   Only one BGSAVE at a time allowed [OK]

Hint: Only one BGSAVE runs at once; wait before retrying [OK]

Common Mistakes:

• Restarting server unnecessarily
• Running SAVE without need
• Flushing data to fix save error

5. You want to ensure Redis creates an RDB snapshot every 5 minutes only if at least 100 keys changed. Which configuration snippet correctly sets this behavior in redis.conf?

hard

A. save 300 100

B. save 100 300

C. save 5 100

D. save 300 5

Solution

1. Step 1: Understand Redis save syntax

   The syntax is save <seconds> <changes>, meaning save if at least <changes> keys changed in <seconds> seconds.

2. Step 2: Match 5 minutes and 100 changes

   5 minutes = 300 seconds, so save 300 100 means save every 300 seconds if 100 keys changed.

3. Final Answer:

   save 300 100 -> Option A

4. Quick Check:

   save seconds changes = save 300 100 [OK]

Hint: save syntax: save seconds changes (time then count) [OK]

Common Mistakes:

• Swapping seconds and changes values
• Using minutes instead of seconds
• Misunderstanding save triggers