Creating an index in Elasticsearch - Performance & Efficiency
When we create an index in Elasticsearch, we want to know how the time it takes changes as we add more data or settings.
We ask: How does the work grow when the index gets bigger or more complex?
Analyze the time complexity of the following code snippet.
PUT /my-index
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 2
},
"mappings": {
"properties": {
"name": { "type": "text" },
"age": { "type": "integer" }
}
}
}
This code creates a new index named "my-index" with specific settings and field mappings.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Setting up shards and replicas, and registering field mappings.
- How many times: The system processes each shard copy (primary and replicas) once during creation.
Explain the growth pattern intuitively.
| Input Size (n) | Approx. Operations |
|---|---|
| 3 shards, 2 replicas | Processes 9 shard copies (3 shards x (1 primary + 2 replicas)) |
| 10 shards, 2 replicas | Processes 30 shard copies |
| 100 shards, 2 replicas | Processes 300 shard copies |
Pattern observation: The work grows linearly with the number of shards and replicas combined.
Time Complexity: O(n)
This means the time to create the index grows in a straight line as you add more shards or replicas.
[X] Wrong: "Creating an index takes the same time no matter how many shards or replicas it has."
[OK] Correct: More shards and replicas mean more pieces to set up, so it takes more time.
Understanding how index creation time grows helps you design efficient data storage and answer questions about scaling in real projects.
"What if we added complex field mappings with many nested fields? How would the time complexity change?"
Practice
Solution
Step 1: Understand the role of an index
An index in Elasticsearch is like a folder that organizes documents to make searching fast and efficient.Step 2: Compare options with index purpose
Deleting, backing up, or encrypting data are not the main functions of an index.Final Answer:
To organize data for fast searching -> Option DQuick Check:
Index = Organize data for search [OK]
- Confusing index with backup or encryption
- Thinking index deletes data
- Assuming index automatically secures data
products in Elasticsearch?Solution
Step 1: Recall HTTP methods for index creation
Elasticsearch uses the PUT method to create an index with a specific name.Step 2: Match method with index name
PUT /products correctly creates the index named 'products'. POST is used for adding documents, GET for retrieving, DELETE for removing.Final Answer:
PUT /products -> Option AQuick Check:
PUT creates index [OK]
- Using POST instead of PUT for index creation
- Confusing GET with creation
- Trying DELETE to create index
{
"settings": {"number_of_shards": 1},
"mappings": {
"properties": {
"name": {"type": "text"},
"price": {"type": "float"}
}
}
}What will be the type of the
price field in the index?Solution
Step 1: Read the mapping for the price field
The mapping defines "price" with "type": "float" which means it stores decimal numbers.Step 2: Understand field types
Float is a number with decimals, integer is whole number, text is for full text search, keyword is for exact matches.Final Answer:
float -> Option BQuick Check:
price type = float [OK]
- Confusing float with integer
- Assuming text type for numbers
- Mixing keyword with numeric types
PUT /library
{
"settings": {
"number_of_shards": "two"
},
"mappings": {
"properties": {
"title": {"type": "text"}
}
}
}Solution
Step 1: Check the settings syntax
number_of_shards must be a numeric value, but "two" is a string, causing an error.Step 2: Validate other parts
Field type 'text' is valid for title, PUT is correct method, index name 'library' is present.Final Answer:
number_of_shards should be a number, not a string -> Option AQuick Check:
number_of_shards = number [OK]
- Using string instead of number for shards
- Confusing field types for text fields
- Using wrong HTTP method for index creation
users with a field age that should only accept whole numbers and be searchable. Which mapping is correct?Solution
Step 1: Understand the data type needed for age
Age is a whole number, so integer type is appropriate to store numeric whole values.Step 2: Check searchability and field types
Text is for full text search, float allows decimals, keyword is for exact matches but not numeric operations.Final Answer:
{ "mappings": { "properties": { "age": { "type": "integer" } } } } -> Option CQuick Check:
Whole number field = integer type [OK]
- Using text type for numeric fields
- Choosing float when decimals not needed
- Using keyword for numeric data
Ready to prove it?
Pass the test and this pattern moves unknown
