Boost Elasticsearch Query Speed: Simple Queries & OS Cache Tricks

When Elasticsearch receives a query request, it forwards it to all relevant shards; each shard searches its own data, aggregates the results, and returns them to the client.

The process has two core performance bottlenecks:

Time spent executing the query on each shard.

I/O time for reading segment files on each shard.

Therefore, optimization should focus on these two aspects:

Keep Elasticsearch queries as simple as possible to avoid complex calculations.

Improve I/O efficiency by leveraging the operating system's file cache.

1. Keep Query Computation Simple

This involves the way data is modeled in Elasticsearch.

In a relational database you might have two tables: an order table (id, total amount, user, date) and an order‑detail table (order id, product info). Queries join these tables, which is natural for relational modeling.

However, Elasticsearch is a search engine and should be modeled from a search perspective. It is better to store related data together in a single document so that a simple query can retrieve everything without requiring joins.

2. Maximize Use of the OS File Cache

The operating system prefers to keep frequently accessed files in memory. When enough RAM is available, segment files are cached, reducing disk reads.

For example, if a cluster has three nodes each holding about 300 GB of data and each node has 16 GB of RAM, only about 5 % of the data can be served from cache; the rest must be read from disk, leading to poor performance.

Two main ways to improve this are:

Increase memory.

Reduce the amount of data stored in Elasticsearch.

2.1 Increase Memory

Adding more RAM is straightforward—if budget allows, add as much as possible.

Guideline: available OS memory should be greater than 50 % of the data size on the node.

2.2 Reduce Data Volume in Elasticsearch

Remember, Elasticsearch is a search engine, not a general storage system. Storing all fields of a large table in ES is unnecessary if many fields are never used in searches.

Only keep data that is relevant to search in ES; store the full dataset in a dedicated storage system such as HBase.

When only a small, search‑relevant subset resides in ES, queries are fast even with modest memory.

First query ES to obtain core fields, then use the keys to fetch detailed data from HBase and merge the results. Although this involves two queries, each is fast, resulting in overall quick response.

2.3 Extended Ideas

Hot‑Cold Separation : Separate frequently accessed (hot) data from rarely accessed (cold) data across different shards to avoid evicting hot data from cache.

Data Pre‑loading : Proactively load hot data into the file cache so that the first user query benefits from cached data.

Conclusion

To achieve fast Elasticsearch queries, keep the query logic simple by thoughtful data modeling, and make the most of the OS file cache.

Increasing memory is a simple, effective method, but reducing the amount of data stored in Elasticsearch—storing only search‑relevant data and offloading the rest to systems like HBase—often yields even greater performance gains.

Additional techniques such as hot‑cold data separation and data pre‑loading can further improve response times.