Sending multiple commands in pipeline in Redis - Time & Space Complexity
When sending many commands to Redis using a pipeline, we want to know how the time to process them grows as we add more commands.
We ask: How does the total work increase when we send more commands together?
Analyze the time complexity of the following code snippet.
MULTI
SET key1 value1
SET key2 value2
SET key3 value3
EXEC
This code sends multiple SET commands inside a transaction pipeline to Redis, executing them all at once.
Look for repeated actions in the code.
- Primary operation: Sending each SET command to Redis.
- How many times: Once for each key-value pair inside the transaction.
As you add more commands, the total work grows roughly by the number of commands.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 commands sent |
| 100 | About 100 commands sent |
| 1000 | About 1000 commands sent |
Pattern observation: The work grows directly with the number of commands you send.
Time Complexity: O(n)
This means if you double the number of commands, the total time roughly doubles too.
[X] Wrong: "Sending commands in a pipeline makes the time stay the same no matter how many commands I send."
[OK] Correct: Even though pipelining reduces network delays, Redis still processes each command one by one, so total time grows with the number of commands.
Understanding how pipelining affects time helps you explain how to handle many commands efficiently in real projects.
What if we sent commands one by one without pipelining? How would the time complexity change?
Practice
Solution
Step 1: Understand what pipelining does
Pipelining sends many commands at once without waiting for each reply, reducing network delays.Step 2: Identify the main benefit
This reduces the number of network round trips, making command execution faster.Final Answer:
It reduces network round trips and speeds up command execution. -> Option BQuick Check:
Pipelining = faster execution [OK]
- Thinking pipelining encrypts commands
- Assuming pipelining compresses data
- Believing pipelining backs up data automatically
Solution
Step 1: Recall Redis transaction commands
Redis transactions start with the command MULTI to begin queuing commands.Step 2: Confirm the correct command
EXEC is used to execute queued commands, not to start the pipeline.Final Answer:
MULTI -> Option AQuick Check:
Start pipeline with MULTI [OK]
- Using EXEC to start instead of end
- Using PIPELINE which is not a Redis command
- Using BEGIN which is not valid in Redis
MULTI SET key1 value1 SET key2 value2 EXECWhat will be the output of the EXEC command?
Solution
Step 1: Understand MULTI/EXEC behavior
Commands between MULTI and EXEC are queued and executed atomically when EXEC runs.Step 2: Analyze the commands SET key1 value1 and SET key2 value2
Each SET command returns "OK" on success.Final Answer:
["OK", "OK"] -> Option DQuick Check:
SET commands return OK in EXEC output [OK]
- Expecting EXEC to return values set
- Confusing EXEC output with command errors
- Thinking EXEC returns numeric success codes
MULTI SET key1 value1 GET key1 EXECBut the GET command returns nil instead of 'value1'. What is the likely cause?
Solution
Step 1: Understand command queuing in MULTI/EXEC
Commands are queued and executed atomically, but GET inside MULTI returns nil because it reads before SET is applied.Step 2: Explain why GET returns nil
GET does not see the queued SET command's effect until after EXEC finishes.Final Answer:
GET command runs before SET in the pipeline, so key1 is not set yet. -> Option CQuick Check:
GET inside MULTI sees old data [OK]
- Assuming GET works immediately inside MULTI
- Thinking DISCARD is needed here
- Believing GET is unsupported in transactions
Solution
Step 1: Identify atomic increment commands
INCR commands increase counters by 1; to run atomically, they must be inside MULTI/EXEC.Step 2: Check each option for correct pipeline usage
MULTI INCR counter1 INCR counter2 EXEC
queues both INCR commands inside MULTI and executes them together with EXEC.Step 3: Explain why others are incorrect
INCR counter1 INCR counter2
runs commands separately, not atomically.MULTI INCR counter1 EXEC INCR counter2 EXEC
splits increments into two transactions.PIPELINE INCR counter1 INCR counter2 EXEC
uses invalid PIPELINE command.Final Answer:
MULTI INCR counter1 INCR counter2 EXEC -> Option AQuick Check:
Atomic increments need MULTI/EXEC [OK]
- Running commands outside MULTI/EXEC for atomicity
- Using invalid PIPELINE command
- Splitting increments into separate transactions
Ready to prove it?
Pass the test and this pattern moves unknown
