Search performance tuning in Elasticsearch - Deep Dive

Overview - Search performance tuning

What is it?

Search performance tuning in Elasticsearch means making your searches faster and more efficient. It involves adjusting settings and organizing data so that queries return results quickly, even with lots of information. This helps users find what they want without waiting. It is important because slow searches can frustrate users and waste resources.

Why it matters

Without tuning search performance, Elasticsearch queries can become slow and costly, especially as data grows. This can lead to unhappy users, lost business, and higher server costs. Good tuning ensures fast, reliable search experiences that scale well, saving time and money while keeping users satisfied.

Where it fits

Before tuning search performance, you should understand basic Elasticsearch concepts like indexes, documents, and queries. After mastering tuning, you can explore advanced topics like cluster scaling, monitoring, and custom plugin development to further improve search systems.

Mental Model

Core Idea

Search performance tuning is about organizing and configuring Elasticsearch so queries find data quickly without wasting resources.

Think of it like...

Imagine a huge library where books are scattered randomly versus one where books are sorted by topic and author. Finding a book in the sorted library is much faster, just like tuned Elasticsearch searches.

┌───────────────┐
│ User Query    │
└──────┬────────┘
       │
┌──────▼────────┐
│ Index Settings│
│ & Mappings   │
└──────┬────────┘
       │
┌──────▼────────┐
│ Data Layout   │
│ (Shards, Docs)│
└──────┬────────┘
       │
┌──────▼────────┐
│ Query Execution│
│ & Caching     │
└──────┬────────┘
       │
┌──────▼────────┐
│ Search Result │
└───────────────┘

Build-Up - 8 Steps

1

Foundation

Understanding Elasticsearch Basics

Concept: Learn what Elasticsearch is and how it stores and searches data.

Elasticsearch stores data in indexes, which are like folders. Each index holds documents, which are like pages with information. When you search, Elasticsearch looks through these documents to find matches. Knowing this helps you see where tuning can help.

Result

You understand the basic structure of Elasticsearch and how searches work.

Understanding the data structure is key to knowing where slowdowns can happen during searches.

2

Foundation

How Queries Work in Elasticsearch

Concept: Learn how Elasticsearch processes search queries internally.

When you send a query, Elasticsearch breaks it down and searches relevant shards (parts of indexes). It scores documents by relevance and returns the best matches. Knowing this helps you see how query complexity affects speed.

Result

You know the path a query takes and what affects its speed.

Knowing query flow helps identify which parts to optimize for faster results.

3

Intermediate

Using Filters to Speed Up Searches

🤔Before reading on: do you think filters and queries are the same in Elasticsearch? Commit to your answer.

Concept: Filters are faster than queries because they don’t score results and can be cached.

Filters quickly include or exclude documents without calculating relevance scores. Using filters for yes/no conditions (like date ranges or categories) speeds up searches because Elasticsearch can cache filter results and reuse them.

Result

Searches using filters run faster and use less CPU.

Understanding the difference between filters and queries unlocks a major way to improve search speed.

4

Intermediate

Optimizing Index Settings and Mappings

🤔Before reading on: do you think storing all fields as searchable text is good for performance? Commit to your answer.

Concept: Choosing the right data types and disabling unnecessary features reduces index size and speeds up searches.

For example, use keyword type for exact matches instead of full text. Disable indexing on fields you don’t search. Avoid storing large fields if not needed. These choices make indexes smaller and queries faster.

Result

Indexes become smaller and searches run more efficiently.

Knowing how to tailor index settings prevents wasted resources and speeds up queries.

5

Intermediate

Leveraging Sharding and Replicas

Concept: Shards split data to allow parallel searching; replicas improve availability and can share search load.

Elasticsearch divides indexes into shards. More shards can mean faster searches because work is split, but too many shards add overhead. Replicas are copies of shards that can serve searches, improving speed and fault tolerance.

Result

Searches can run faster and more reliably with proper shard and replica setup.

Balancing shard count and replicas is crucial for scaling search performance.

6

Advanced

Using Caching to Improve Query Speed

🤔Before reading on: do you think Elasticsearch caches all queries automatically? Commit to your answer.

Concept: Elasticsearch caches filter results and query results selectively to speed up repeated searches.

Filters are cached automatically, but query caching depends on query type and settings. You can tune cache sizes and expiration. Proper caching reduces CPU and disk reads for frequent queries.

Result

Repeated queries run much faster due to caching.

Knowing caching behavior helps you design queries and filters that benefit most from it.

7

Advanced

Controlling Result Size and Pagination

Concept: Limiting how many results Elasticsearch returns and how it pages through them affects performance.

Requesting only needed fields and limiting result size reduces data transfer and processing. Deep pagination (large offsets) is slow because Elasticsearch must collect and sort many hits. Using search_after or scroll APIs helps with large result sets.

Result

Searches return results faster and use fewer resources.

Understanding pagination limits prevents slow queries and resource exhaustion.

8

Expert

Advanced Query Profiling and Hotspot Analysis

🤔Before reading on: do you think all slow queries are caused by large data size? Commit to your answer.

Concept: Profiling tools reveal exactly which parts of a query or index cause slowdowns, beyond just data size.

Elasticsearch’s profile API breaks down query execution time by phase and component. This helps find unexpected bottlenecks like expensive scripts, slow filters, or heavy scoring. Fixing these hotspots can drastically improve performance.

Result

You can pinpoint and fix hidden causes of slow searches.

Knowing how to profile queries reveals surprises that simple tuning misses, enabling expert-level optimization.

Under the Hood

Elasticsearch stores data in inverted indexes, which map terms to documents. When a query runs, it looks up terms in these indexes to find matching documents quickly. It scores matches using algorithms like TF-IDF or BM25. Filters skip scoring and use bitsets for fast inclusion/exclusion. Shards allow parallel processing, and caching stores results in memory for reuse.

Why designed this way?

Elasticsearch was designed for fast full-text search at scale. Inverted indexes are a proven method for quick term lookup. Sharding and replication enable horizontal scaling and fault tolerance. Caching and filters optimize repeated queries. This design balances speed, flexibility, and reliability.

┌───────────────┐
│ User Query    │
└──────┬────────┘
       │
┌──────▼────────┐
│ Query Parser  │
└──────┬────────┘
       │
┌──────▼────────┐
│ Inverted Index│
│ Lookup       │
└──────┬────────┘
       │
┌──────▼────────┐
│ Scoring &    │
│ Filtering    │
└──────┬────────┘
       │
┌──────▼────────┐
│ Caching Layer │
└──────┬────────┘
       │
┌──────▼────────┐
│ Result Return │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does adding more shards always make searches faster? Commit to yes or no.

Common Belief: More shards always mean faster searches because work is split more.

Reality: Too many shards add overhead and can slow down searches due to coordination costs.

Why it matters: Over-sharding wastes resources and hurts performance instead of helping.

Quick: Are filters and queries treated the same in caching? Commit to yes or no.

Common Belief: Filters and queries are cached equally by Elasticsearch.

Reality: Filters are cached automatically; queries are cached only in certain cases and need tuning.

Why it matters: Misunderstanding caching leads to missed optimization opportunities.

Quick: Does increasing result size always improve user experience? Commit to yes or no.

Common Belief: Returning more results per query is always better for users.

Reality: Large result sets slow queries and often overwhelm users; smaller, focused results are better.

Why it matters: Ignoring this causes slow searches and poor user satisfaction.

Quick: Is slow search always caused by large data volume? Commit to yes or no.

Common Belief: If searches are slow, it’s because the data is too big.

Reality: Slow searches can be caused by inefficient queries, bad mappings, or lack of caching, not just data size.

Why it matters: Assuming only data size causes slowness leads to wrong fixes and wasted effort.

Expert Zone

1

Shard size balance is critical: too small shards increase overhead, too large shards reduce parallelism.

2

Query DSL complexity impacts performance more than raw data size; simple queries often outperform complex ones on large data.

3

Caching effectiveness depends on query patterns; unpredictable queries gain little from caching.

When NOT to use

Search performance tuning is less effective if the cluster hardware is insufficient or network latency dominates. In such cases, upgrading hardware or optimizing infrastructure is better. Also, for extremely large datasets, consider using specialized search engines or data warehouses designed for big data.

Production Patterns

In production, teams use monitoring tools like Elastic APM and Kibana to track query latency and hotspots. They implement query templates with filters for common searches, tune index refresh intervals, and use rollover indexes to manage data growth. Hot shards are rebalanced, and slow logs help identify problematic queries.

Connections

Database Indexing

Builds-on

Understanding traditional database indexing helps grasp how Elasticsearch’s inverted indexes speed up text search.

Caching in Web Browsers

Same pattern

Both Elasticsearch and browsers cache results to avoid repeating expensive operations, improving speed and user experience.

Supply Chain Optimization

Analogous process

Just as supply chains optimize routes and inventory to deliver goods faster, search tuning optimizes data layout and queries to deliver results faster.

Common Pitfalls

#1 Requesting all fields in every search slows down queries.

Wrong approach:

{ "query": { "match_all": {} }, "_source": true }

Correct approach:

{ "query": { "match_all": {} }, "_source": ["title", "date"] }

Root cause:

Not limiting returned fields causes Elasticsearch to load unnecessary data, wasting time and resources.

#2 Using deep pagination with large from values causes slow searches.

Wrong approach:

{ "query": { "match": { "content": "example" } }, "from": 10000, "size": 10 }

Correct approach:

Use search_after or scroll API for deep pagination instead of large from offsets.

Root cause:

Large offsets force Elasticsearch to sort and skip many documents, which is inefficient.

#3 Indexing all fields as full text even if not searched.

Wrong approach:

"mappings": { "properties": { "id": { "type": "text" }, "status": { "type": "text" } } }

Correct approach:

"mappings": { "properties": { "id": { "type": "keyword" }, "status": { "type": "keyword" } } }

Root cause:

Misunderstanding field types leads to larger indexes and slower queries.

Key Takeaways

Search performance tuning makes Elasticsearch queries faster by organizing data and queries efficiently.

Filters are faster than queries and benefit greatly from caching, so use them for yes/no conditions.

Proper index settings and shard management balance speed and resource use.

Avoid deep pagination with large offsets; use search_after or scroll for large result sets.

Profiling queries reveals hidden bottlenecks that simple tuning misses, enabling expert optimization.

Practice

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