Time Complexity: Hot-warm-cold architecture
O(n)
0
0
Hot-warm-cold architecture in Elasticsearch - Time & Space Complexity
Understanding Time Complexity
When using hot-warm-cold architecture in Elasticsearch, we want to understand how query time changes as data grows across different storage layers.
We ask: How does the time to search or manage data grow when data moves between hot, warm, and cold nodes?
Scenario Under Consideration
Analyze the time complexity of a search query routed through hot, warm, and cold nodes.
GET /logs-*/_search
{
"query": {
"match": { "message": "error" }
}
}
This query searches logs spread across hot, warm, and cold nodes, each storing different data ages.
Identify Repeating Operations
Look at how the query runs on each node type.
- Primary operation: Searching through shards on hot, warm, and cold nodes.
- How many times: Once per shard in each node tier holding relevant data.
How Execution Grows With Input
As data grows, more shards exist in warm and cold nodes, increasing search time.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 GB | Searches mostly on hot nodes, fewer shards. |
| 100 GB | More shards on warm nodes, search time grows moderately. |
| 1 TB | Many shards on cold nodes, search time grows more. |
Pattern observation: Search time grows roughly with the number of shards queried across tiers.
Final Time Complexity
Time Complexity: O(n)
This means search time grows linearly with the amount of data spread across hot, warm, and cold nodes.
Common Mistake
[X] Wrong: "Searching cold nodes is always slow regardless of data size."
[OK] Correct: Cold nodes can be optimized with fewer shards or slower hardware, but search time depends on data size and shard count, not just node type.
Interview Connect
Understanding how data tiering affects search time helps you design scalable Elasticsearch clusters and explain performance trade-offs clearly.
Self-Check
"What if we combined warm and cold nodes into a single tier? How would the time complexity change?"