Index settings (shards, replicas) in Elasticsearch - Time & Space Complexity
When working with Elasticsearch, the way we set shards and replicas affects how fast queries and indexing happen.
We want to understand how the number of shards and replicas changes the work Elasticsearch does.
Analyze the time complexity of this index settings configuration.
PUT /my-index
{
"settings": {
"number_of_shards": 5,
"number_of_replicas": 1
}
}
This code creates an index with 5 primary shards and 1 replica for each shard.
Look at what happens when Elasticsearch processes data with these settings.
- Primary operation: Writing a document to its primary shard (determined by hash) and replicating it to the replicas of that shard.
- How many times: 1 (primary) + r (replicas) times per document.
As the data size grows, Elasticsearch splits it across shards and copies it to replicas.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 * (1 + 1) = 20 writes (spread across up to 5 shards) |
| 100 | 100 * (1 + 1) = 200 writes (spread across up to 5 shards) |
| 1000 | 1000 * (1 + 1) = 2000 writes (spread across up to 5 shards) |
Pattern observation: The total work grows linearly with data size n, multiplied by (1 + r). The number of shards s allows distributing these writes for better parallelism.
Time Complexity: O(n * (1 + r))
This means the work grows linearly with data size n, multiplied by the replication factor (1 + r). Number of shards s does not affect total writes but enables parallel processing.
[X] Wrong: "Adding more replicas makes indexing faster because data is copied in parallel."
[OK] Correct: Replicas add extra work because data must be written multiple times, so indexing actually takes more time overall.
Understanding how shards and replicas affect work helps you explain Elasticsearch performance clearly and confidently.
"What if we increased the number of shards but kept replicas the same? How would the time complexity change?"
Practice
number_of_shards in an Elasticsearch index?Solution
Step 1: Understand shards role
Shards divide the index data into smaller parts to allow parallel searching.Step 2: Differentiate shards from replicas
Replicas are copies for safety, not for splitting data.Final Answer:
To split data into parts for faster searching -> Option CQuick Check:
Shards = split data for speed [OK]
- Confusing shards with replicas
- Thinking shards create backups
- Assuming shards set index size
Solution
Step 1: Recall correct setting keys
The official keys arenumber_of_shardsandnumber_of_replicas.Step 2: Match keys with options
Only { "settings": { "number_of_shards": 3, "number_of_replicas": 2 } } uses the exact correct keys and valid JSON format.Final Answer:
{ "settings": { "number_of_shards": 3, "number_of_replicas": 2 } } -> Option AQuick Check:
Correct keys = number_of_shards, number_of_replicas [OK]
- Using shorthand keys like shards or replicas
- Wrong JSON syntax
- Mixing shard and replica counts
number_of_shards set to 4 and number_of_replicas set to 1, how many total shard copies exist in the cluster?Solution
Step 1: Calculate primary shards
There are 4 primary shards as set.Step 2: Calculate replica shards
Each primary shard has 1 replica, so 4 replicas total.Step 3: Add primary and replicas
Total shards = 4 primary + 4 replicas = 8 shards.Final Answer:
8 -> Option DQuick Check:
Total shards = primary + replicas = 8 [OK]
- Counting only primary shards
- Adding shards and replicas incorrectly
- Confusing replicas with shards
{ "settings": { "number_of_shards": 2, "number_of_replicas": -1 } }. What is the problem?Solution
Step 1: Check shards value
Number of shards is 2, which is valid.Step 2: Check replicas value
Replicas cannot be negative; -1 is invalid.Final Answer:
Negative replicas value is invalid -> Option AQuick Check:
Replicas must be zero or positive [OK]
- Assuming negative replicas mean no replicas
- Thinking shards must be > 3
- Ignoring JSON correctness
Solution
Step 1: Understand shards and replicas roles
Shards split data for speed; replicas provide copies for safety.Step 2: Evaluate options for availability and speed
{ "number_of_shards": 5, "number_of_replicas": 1 } keeps 5 shards for speed and 1 replica for safety, balancing both.Step 3: Reject other options
The option with zero replicas has no safety, the option with 1 shard is slow for search, the option with 10 shards has overhead.Final Answer:
{ "number_of_shards": 5, "number_of_replicas": 1 } -> Option BQuick Check:
Balance shards and replicas for speed and safety [OK]
- Setting zero replicas for safety
- Using too few shards for speed
- Over-sharding causing overhead
Ready to prove it?
Pass the test and this pattern moves unknown
