Key design patterns in Redis - Time & Space Complexity
When using Redis key design patterns, it is important to understand how the time to access or modify keys changes as the number of keys grows.
We want to know how the operations scale when we use common patterns like namespaces or key prefixes.
Analyze the time complexity of accessing keys with a common prefix pattern.
# Set keys with a prefix
SET user:1001 "Alice"
SET user:1002 "Bob"
SET user:1003 "Carol"
# Retrieve keys by prefix
KEYS user:*
This code sets several keys with the prefix "user:" and then retrieves all keys starting with that prefix.
Look for operations that repeat or scan through data.
- Primary operation: The
KEYScommand scans all keys to find matches. - How many times: It checks every key in the database once.
As the number of keys grows, the time to run KEYS user:* grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 key checks |
| 100 | 100 key checks |
| 1000 | 1000 key checks |
Pattern observation: The number of operations grows directly with the number of keys.
Time Complexity: O(n)
This means the time to find keys with a prefix grows linearly as the total number of keys increases.
[X] Wrong: "Using key prefixes makes key searches instant regardless of database size."
[OK] Correct: The KEYS command still scans all keys, so the time depends on total keys, not just the prefix.
Understanding how key patterns affect performance helps you design efficient Redis databases and answer questions about scaling data access.
"What if we replaced KEYS with SCAN for prefix matching? How would the time complexity change?"
Practice
Solution
Step 1: Understand Redis key design patterns
Key design patterns help organize Redis keys logically.Step 2: Identify the main benefit
Organizing keys makes data easier to access and manage efficiently.Final Answer:
To organize data for easy access and management -> Option BQuick Check:
Key design patterns = organize data [OK]
- Confusing organization with database size
- Assuming patterns slow down Redis
- Thinking patterns delete keys automatically
Solution
Step 1: Identify common Redis key pattern syntax
Redis keys often use colons ':' as separators for readability and grouping.Step 2: Compare options
user:1234:name uses colons to separate user, ID, and attribute clearly.Final Answer:
user:1234:name -> Option AQuick Check:
Colon separators = correct pattern [OK]
- Using dashes or slashes which are less common
- Not separating parts clearly
- Combining all parts without separators
order:1001:status, order:1002:status, and order:1001:items, which command retrieves the status of order 1002?Solution
Step 1: Identify the key for order 1002 status
The key format is order:<order_id>:status, so for 1002 it is order:1002:status.Step 2: Match the command to the key
GET order:1002:status retrieves the status of order 1002.Final Answer:
GET order:1002:status -> Option CQuick Check:
Correct key = order:1002:status [OK]
- Mixing order IDs in keys
- Using wrong attribute like items instead of status
- Confusing similar keys
session-123 and session:124. Why might this inconsistency cause problems?Solution
Step 1: Understand key pattern consistency
Consistent key patterns help group and find related data easily.Step 2: Analyze the impact of mixed separators
Using both dashes and colons breaks this consistency, causing confusion.Final Answer:
It breaks pattern consistency, making data harder to manage -> Option DQuick Check:
Inconsistent keys = management issues [OK]
- Thinking Redis forbids dashes
- Expecting syntax errors from mixed separators
- Assuming Redis merges keys automatically
Solution
Step 1: Identify clear, scalable key pattern
Using colons to separate product and user IDs groups reviews logically.Step 2: Evaluate options for clarity and consistency
review:<product_id>:<user_id> uses colons and a prefix 'review' for easy filtering and management.Final Answer:
review:<product_id>:<user_id> -> Option AQuick Check:
Colon-separated keys = best practice [OK]
- Using ambiguous separators like dashes or slashes
- Combining parts without separators
- Not using a clear prefix for grouping
Ready to prove it?
Pass the test and this pattern moves unknown
