Bird
Raised Fist0
Elasticsearchquery~5 mins

Search performance tuning in Elasticsearch - Time & Space Complexity

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Time Complexity: Search performance tuning
O(n)
Understanding Time Complexity

When tuning search performance in Elasticsearch, we want to understand how the time it takes to find results changes as the data grows.

We ask: How does search speed change when we add more documents or queries?

Scenario Under Consideration

Analyze the time complexity of this Elasticsearch search query with filters and sorting.


GET /products/_search
{
  "query": {
    "bool": {
      "filter": [
        { "term": { "category": "books" }},
        { "range": { "price": { "lte": 20 }}}
      ]
    }
  },
  "sort": [ { "rating": "desc" } ]
}
    

This query filters products by category and price, then sorts results by rating.

Identify Repeating Operations

Look for repeated work inside the search process.

  • Primary operation: Scanning matching documents to apply filters and sorting.
  • How many times: Once per matching document in the filtered set.
How Execution Grows With Input

As the number of documents grows, the search engine checks more items to find matches and sort them.

Input Size (n)Approx. Operations
10About 10 checks and sorts
100About 100 checks and sorts
1000About 1000 checks and sorts

Pattern observation: The work grows roughly in direct proportion to the number of matching documents.

Final Time Complexity

Time Complexity: O(n)

This means the search time grows linearly with the number of documents that match the filters.

Common Mistake

[X] Wrong: "Adding filters always makes search faster because it reduces data to check."

[OK] Correct: Some filters can be slow if they are not indexed well, causing Elasticsearch to scan many documents anyway.

Interview Connect

Understanding how search time grows helps you explain how to keep queries fast as data grows, a key skill in real projects.

Self-Check

"What if we added a full-text search instead of a term filter? How would the time complexity change?"

Practice

(1/5)
1. Which of the following is a common way to improve search performance in Elasticsearch?
easy
A. Limit the number of results returned using size parameter
B. Increase the number of shards without limit
C. Disable caching completely
D. Use wildcard queries on all fields

Solution

  1. Step 1: Understand result limiting

    Limiting results with size reduces data processed and returned, speeding up queries.
  2. Step 2: Evaluate other options

    Increasing shards without limit can hurt performance, disabling cache reduces speed, and wildcard queries are slow.
  3. Final Answer:

    Limit the number of results returned using size parameter -> Option A
  4. Quick Check:

    Limiting results = faster search [OK]
Hint: Use size to limit results for faster queries [OK]
Common Mistakes:
  • Thinking more shards always improve speed
  • Ignoring caching benefits
  • Using wildcard queries on all fields
2. Which Elasticsearch query syntax correctly limits the returned fields to only title and author?
easy
A. {"return_fields": ["title", "author"], "query": {"match_all": {}}}
B. {"fields": ["title", "author"], "query": {"match_all": {}}}
C. {"select": ["title", "author"], "query": {"match_all": {}}}
D. {"_source": ["title", "author"], "query": {"match_all": {}}}

Solution

  1. Step 1: Identify correct field limiting syntax

    Elasticsearch uses _source to specify which fields to return.
  2. Step 2: Check other options

    fields, select, and return_fields are not valid for limiting returned fields in this context.
  3. Final Answer:

    {"_source": ["title", "author"], "query": {"match_all": {}}} -> Option D
  4. Quick Check:

    Use _source to limit fields [OK]
Hint: Use _source to specify returned fields [OK]
Common Mistakes:
  • Using fields instead of _source
  • Trying SQL-like select syntax
  • Using unsupported keys like return_fields
3. Given this Elasticsearch query, what will be the effect of adding "timeout": "2s"?
{
  "query": {"match": {"content": "fast search"}},
  "timeout": "2s"
}
medium
A. The query will fail if it takes longer than 2 seconds
B. The query will cache results for 2 seconds
C. The query will return partial results after 2 seconds
D. The query will wait 2 seconds before starting

Solution

  1. Step 1: Understand timeout behavior

    Elasticsearch's timeout stops the query after the specified time and returns partial results if available.
  2. Step 2: Evaluate other options

    It does not fail immediately, does not delay start, and does not control caching.
  3. Final Answer:

    The query will return partial results after 2 seconds -> Option C
  4. Quick Check:

    timeout returns partial results [OK]
Hint: Timeout returns partial results if query is slow [OK]
Common Mistakes:
  • Assuming timeout causes query failure
  • Thinking timeout delays query start
  • Confusing timeout with caching duration
4. You have this query to limit results and fields:
{
  "size": 10,
  "query": {
    "_source": ["title", "date"],
    "match_all": {}
  }
}
But the query returns all fields. What is the likely mistake?
medium
A. Using size instead of limit
B. Using _source inside the query body instead of top-level
C. Missing fields parameter to limit fields
D. The match_all query ignores field limits

Solution

  1. Step 1: Check placement of _source

    _source must be at the top level of the query JSON, not inside query.
  2. Step 2: Review other options

    fields is deprecated for this purpose, size is correct, and match_all does not ignore field limits.
  3. Final Answer:

    Using _source inside the query body instead of top-level -> Option B
  4. Quick Check:

    _source must be top-level [OK]
Hint: Place _source at top level, not inside query [OK]
Common Mistakes:
  • Putting _source inside query
  • Confusing size with limit
  • Assuming match_all ignores field filtering
5. You want to optimize a search that returns many documents but only needs the id and summary fields, and must respond within 1 second. Which combination of settings best improves performance?
hard
A. Set size to a low number, use _source to limit fields, and add timeout of 1s
B. Set size high, disable _source, and remove timeout
C. Use wildcard queries on all fields and set timeout to 5s
D. Increase shards count and use fields to limit fields

Solution

  1. Step 1: Limit results and fields

    Setting size low reduces returned documents; _source limits fields to needed ones.
  2. Step 2: Use timeout to keep response fast

    Adding timeout of 1 second ensures query won't hang and keeps system responsive.
  3. Step 3: Evaluate other options

    High size and disabling _source increase load; wildcard queries are slow; increasing shards without need can hurt performance.
  4. Final Answer:

    Set size to a low number, use _source to limit fields, and add timeout of 1s -> Option A
  5. Quick Check:

    Limit size + fields + timeout = best performance [OK]
Hint: Limit size, fields, and add timeout for fast, efficient search [OK]
Common Mistakes:
  • Setting size too high
  • Disabling field filtering
  • Ignoring timeout setting
  • Increasing shards unnecessarily