AOF rewrite process in Redis - Time & Space Complexity
We want to understand how the time needed for Redis to rewrite its Append Only File (AOF) changes as the data grows.
How does the rewrite process scale when more data is stored?
Analyze the time complexity of the AOF rewrite process in Redis.
// Pseudocode for AOF rewrite process
start AOF rewrite
for each key in database {
get key type
get key value
write command to new AOF file
}
finish AOF rewrite
This code loops over all keys in the database, reads their data, and writes commands to a new AOF file to compact the data.
Look for repeated actions in the rewrite process.
- Primary operation: Looping over every key in the database.
- How many times: Once for each key stored in Redis.
The time to rewrite grows as the number of keys grows, because each key must be processed once.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 key reads and writes |
| 100 | About 100 key reads and writes |
| 1000 | About 1000 key reads and writes |
Pattern observation: The work grows directly with the number of keys; doubling keys roughly doubles the work.
Time Complexity: O(n)
This means the rewrite time grows in a straight line with the number of keys stored.
[X] Wrong: "The rewrite time stays the same no matter how many keys there are."
[OK] Correct: Because Redis must process every key to write it to the new file, more keys mean more work and longer rewrite time.
Understanding how Redis handles data persistence and its costs helps you explain real-world database behavior clearly and confidently.
"What if Redis only rewrote keys that changed since the last rewrite? How would the time complexity change?"
Practice
Solution
Step 1: Understand the role of AOF in Redis
The Append Only File (AOF) logs every write operation to Redis for durability.Step 2: Identify what rewrite does
The rewrite process compacts the AOF by removing redundant commands, saving disk space and improving startup speed.Final Answer:
To clean and compact the Append Only File to save disk space -> Option DQuick Check:
AOF rewrite = compacts file to save space [OK]
- Confusing AOF rewrite with backup process
- Thinking it increases memory usage
- Believing it deletes data
Solution
Step 1: Recall commands related to persistence
SAVE and BGSAVE are for RDB snapshots, FLUSHALL deletes keys.Step 2: Identify the command for AOF rewrite
BGREWRITEAOF triggers background AOF rewrite without stopping Redis.Final Answer:
BGREWRITEAOF -> Option CQuick Check:
BGREWRITEAOF = background AOF rewrite [OK]
- Using SAVE which blocks Redis
- Confusing BGSAVE (RDB snapshot) with AOF rewrite
- Using FLUSHALL which clears data
SET key1 value1 APPEND key1 _extra BGREWRITEAOFWhat is the expected effect on the AOF file after BGREWRITEAOF completes?
Solution
Step 1: Understand the commands effect
SET key1 value1 sets key1, APPEND adds '_extra' to its value.Step 2: Understand BGREWRITEAOF effect
BGREWRITEAOF rewrites AOF to contain minimal commands to recreate current state, so it will store SET key1 value1_extra.Final Answer:
The AOF file will contain only the latest state of key1 with value 'value1_extra' -> Option AQuick Check:
BGREWRITEAOF compacts commands to current state [OK]
- Thinking all commands remain in AOF
- Assuming AOF is emptied
- Believing AOF is deleted
BGREWRITEAOF but notice the AOF file size does not reduce. What could be a likely cause?Solution
Step 1: Consider reasons for no size reduction
If AOF is already compact, rewriting won't reduce size.Step 2: Evaluate other options
Failure due to disk space would cause errors; server stop would abort rewrite; BGSAVE does RDB snapshot, not AOF rewrite.Final Answer:
The AOF file was already compact and minimal -> Option BQuick Check:
No size change means AOF already minimal [OK]
- Assuming rewrite always reduces size
- Confusing BGSAVE with BGREWRITEAOF
- Ignoring disk space errors
Solution
Step 1: Understand what affects Redis startup speed
Redis loads data by replaying commands in the AOF file; fewer commands mean faster loading.Step 2: Analyze options
Rewrite does not compress with gzip, delete expired keys at startup, or move files to faster disks.Final Answer:
Because the rewritten AOF file contains fewer commands, Redis loads data faster -> Option AQuick Check:
Fewer commands in AOF = faster startup [OK]
- Thinking rewrite compresses with gzip
- Believing expired keys are deleted by rewrite
- Assuming file is moved to faster disk
Ready to prove it?
Pass the test and this pattern moves unknown
