Why persistence matters in Redis - Performance Analysis
When using Redis, persistence means saving data so it is not lost if the server stops.
We want to understand how saving data affects the time it takes to run commands.
Analyze the time complexity of saving data with Redis persistence commands.
SET user:1 "Alice"
SET user:2 "Bob"
SAVE
SET user:3 "Carol"
BGSAVE
This code sets some keys and triggers saving data to disk synchronously and asynchronously.
Look for operations that repeat or take time based on data size.
- Primary operation: Saving the entire dataset to disk (SAVE or BGSAVE)
- How many times: Once per SAVE or BGSAVE command, but the cost depends on data size
Saving data takes longer as the amount of data grows.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 keys | Small, quick save |
| 100 keys | About 10 times longer save |
| 1000 keys | About 10 times longer save |
Pattern observation: The time to save grows roughly with the amount of data, so more data means more time.
Time Complexity: O(n)
This means saving data takes time proportional to how much data you have.
[X] Wrong: "Saving data always takes the same short time regardless of data size."
[OK] Correct: Saving writes all data to disk, so more data means more work and longer time.
Understanding how persistence affects performance helps you design systems that keep data safe without slowing down too much.
"What if Redis used incremental saving instead of saving all data at once? How would the time complexity change?"
Practice
Solution
Step 1: Understand persistence purpose
Persistence means saving data to disk so it is not lost when Redis restarts or crashes.Step 2: Compare options
Only the option stating 'It saves data to disk to prevent data loss after a restart.' describes saving data to disk to prevent loss. Others describe caching, deleting, or encryption, which are unrelated to persistence.Final Answer:
It saves data to disk to prevent data loss after a restart. -> Option CQuick Check:
Persistence = saving data safely [OK]
- Confusing persistence with caching
- Thinking persistence deletes data
- Mixing persistence with encryption
Solution
Step 1: Identify persistence settings
Redis uses thesaveoption to specify intervals for saving snapshots to disk.Step 2: Eliminate other options
maxmemory-policycontrols eviction,appendonlyenables AOF persistence, andtimeoutsets client timeout, not snapshot frequency.Final Answer:
save -> Option AQuick Check:
save = snapshot frequency setting [OK]
- Confusing appendonly with save
- Thinking maxmemory-policy controls saving
- Mixing timeout with persistence
save 900 1 save 300 10 save 60 10000
What does this configuration mean?
Solution
Step 1: Understand Redis save syntax
Each line means: save after X seconds if at least Y keys changed. For example,save 900 1means save after 900 seconds if 1 or more keys changed.Step 2: Match lines to meaning
Lines specify different intervals and minimum changed keys: 900s/1 key, 300s/10 keys, 60s/10000 keys.Final Answer:
Save data every 900 seconds if at least 1 key changed, every 300 seconds if 10 keys changed, and every 60 seconds if 10000 keys changed. -> Option AQuick Check:
save X Y means save after X seconds if Y keys changed [OK]
- Ignoring the minimum changed keys condition
- Assuming save happens regardless of changes
- Mixing seconds and keys numbers
appendonly yes in Redis config but data is not saved after restart. What is the likely problem?Solution
Step 1: Understand AOF persistence
Settingappendonly yesenables AOF persistence, which logs every write operation to a file.Step 2: Identify why data might not persist
If the AOF file is missing or corrupted, Redis cannot restore data on restart, causing data loss despite the setting.Final Answer:
The appendonly.aof file is missing or corrupted. -> Option DQuick Check:
AOF file missing = no data restored [OK]
- Thinking appendfsync 'no' disables AOF (it controls fsync frequency)
- Assuming save option affects AOF
- Forgetting to restart Redis after config changes
Solution
Step 1: Understand persistence options
RDB snapshots save data at intervals (e.g., every 300 seconds). AOF logs every write and can fsync every second.Step 2: Match requirement to config
To lose no more than 5 minutes (300 seconds) of data, snapshots alone are risky. Combining snapshots every 300s with AOF fsync every second minimizes data loss.Step 3: Evaluate options
The option to enable both RDB snapshots every 300 seconds and AOF with appendfsync 'everysec' enables both methods with appropriate intervals, ensuring minimal data loss. Others either save less often or disable persistence.Final Answer:
Enable both RDB snapshots every 300 seconds and AOF with appendfsync 'everysec'. -> Option BQuick Check:
Combine snapshots + AOF for best data safety [OK]
- Relying on snapshots alone for short data loss windows
- Disabling persistence to improve speed
- Setting appendfsync to 'no' or 'always' incorrectly
Ready to prove it?
Pass the test and this pattern moves unknown
