Lua vs transactions comparison in Redis - Performance Comparison
We want to understand how the time cost changes when using Lua scripts versus transactions in Redis.
Which method grows faster in execution time as the input size increases?
Analyze the time complexity of these two Redis approaches.
-- Lua script example
local vals = redis.call('LRANGE', KEYS[1], 0, -1)
for i, v in ipairs(vals) do
redis.call('HSET', KEYS[2], v, i)
end
-- Transaction example
MULTI
LRANGE mylist 0 -1
HSET myhash field1 val1
EXEC
The Lua script runs commands inside one script; the transaction groups commands to run atomically.
Look for repeated steps that affect time.
- Primary operation: Loop inside Lua script calling HSET for each list item.
- How many times: Once per list element (n times).
As the list size grows, the Lua script runs more HSET commands in one go.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 HSET calls inside Lua |
| 100 | About 100 HSET calls inside Lua |
| 1000 | About 1000 HSET calls inside Lua |
Pattern observation: The Lua script time grows roughly linearly with the number of list items.
Time Complexity: O(n)
This means the time grows in direct proportion to the number of items processed.
[X] Wrong: "Lua scripts always run instantly no matter the input size."
[OK] Correct: Lua scripts still do work for each item, so time grows with input size.
Knowing how Lua scripts and transactions scale helps you choose the right tool for efficient Redis operations.
What if the Lua script called multiple Redis commands per list item? How would the time complexity change?
Practice
Solution
Step 1: Understand atomic execution in Redis
Both Lua scripts and transactions ensure commands run atomically, meaning all commands execute as one unit without interruption.Step 2: Compare complexity and usage
Lua scripts allow embedding complex logic and multiple commands in one script, while transactions simply group commands without logic.Final Answer:
Lua scripts allow complex logic, while transactions group simple commands atomically. -> Option CQuick Check:
Lua = complex logic, transactions = simple groups [OK]
- Thinking transactions can run complex logic
- Believing Lua scripts do not guarantee atomicity
- Confusing speed differences between Lua and transactions
Solution
Step 1: Recall Redis transaction commands
Redis transactions start with the MULTI command to begin queuing commands.Step 2: Identify correct command usage
EXEC is used to execute queued commands, EVAL runs Lua scripts, SCRIPT manages scripts, so MULTI is the correct start.Final Answer:
MULTI -> Option AQuick Check:
Start transaction with MULTI [OK]
- Using EXEC to start a transaction
- Confusing EVAL with transaction commands
- Using SCRIPT to start transactions
local val = redis.call('GET', KEYS[1])
if val == nil then
redis.call('SET', KEYS[1], ARGV[1])
return ARGV[1]
else
return val
end
What will be the output if the key does not exist and ARGV[1] is "hello"?Solution
Step 1: Check key existence with redis.call('GET')
If the key does not exist, redis.call('GET') returns nil in Lua script context.Step 2: Set key and return ARGV[1]
Since val == nil, the script sets the key to ARGV[1] which is "hello" and returns "hello".Final Answer:
"hello" -> Option DQuick Check:
Key missing sets and returns ARGV[1] = "hello" [OK]
- Thinking GET returns false instead of nil
- Expecting nil or error instead of returned value
- Confusing Lua false with Redis nil
MULTI GET key1 SET key1 value1 EXECBut the GET command returns nil instead of "value1". What is the likely cause?
Solution
Step 1: Understand Redis transaction command queuing
Commands inside MULTI are queued and executed only after EXEC; GET does not see SET effect during queuing.Step 2: Explain why GET returns nil
GET is queued before SET, so during EXEC it executes first and returns nil because SET has not been applied yet.Final Answer:
GET runs before SET executes in transaction -> Option BQuick Check:
Queued commands run after EXEC, GET sees old value [OK]
- Thinking commands run immediately inside MULTI
- Assuming GET syntax error causes nil
- Believing EXEC was not called
Solution
Step 1: Understand atomic conditional increment need
Increment only if value < 10 requires checking and updating atomically to avoid race conditions.Step 2: Compare Lua script vs transactions
Lua scripts run all logic atomically in Redis, while transactions cannot conditionally check and increment atomically without race.Step 3: Evaluate WATCH option
WATCH can detect changes but requires retry logic and is less clean than Lua script for this logic.Final Answer:
Use a Lua script to check and increment atomically -> Option AQuick Check:
Lua scripts handle complex atomic logic best [OK]
- Assuming transactions can do conditional increments atomically
- Ignoring race conditions with separate GET and INCR
- Overestimating WATCH simplicity without retries
Ready to prove it?
Pass the test and this pattern moves unknown
