Elasticsearch Interview Question: Performance Optimization and Best Practices

Interview question : How to boost query efficiency in Elasticsearch when dealing with tens of billions of records?

Interviewer analysis : Candidates who have hands‑on experience with ES will notice that large data sets can cause initial searches to take 5–10 seconds, while subsequent queries become faster after caching.

Performance optimization insight : There is no silver bullet; you cannot rely on a single parameter tweak to solve all latency issues.

Filesystem cache as the key : ES writes data to disk, and the operating system caches these files in the filesystem cache . Allocating enough memory for this cache to hold most index segment files dramatically improves search speed, often reducing latency from seconds to milliseconds.

Example: A three‑node cluster with 64 GB RAM each (total 192 GB) allocates 32 GB JVM heap per node, leaving 32 GB per node (96 GB total) for the filesystem cache. If the total index size is 1 TB, only ~10% fits in cache, leading to slow disk‑bound queries.

Best practice : Ensure the memory available for the filesystem cache is at least half of the total data size, or store only the fields needed for search in ES and keep the rest in a secondary store such as MySQL or HBase.

Data pre‑heating : Periodically run background queries on hot data (e.g., popular user profiles or frequently viewed products) to keep them resident in the cache, thus delivering near‑instant responses for end users.

Hot‑cold separation : Create separate indices for hot (frequently accessed) and cold (rarely accessed) data, distributing them across different nodes to prevent cold data from evicting hot data from the cache.

Document model design : Avoid complex joins or nested queries in ES; instead, denormalize data at write time, storing only searchable fields (e.g., id, name, age) in ES and keeping the full record elsewhere.

Pagination performance : Deep pagination is costly because each shard must return thousands of documents to the coordinating node. Solutions include:

Disallow deep pagination in product requirements.

Use the scroll API for endless scrolling scenarios, which keeps a snapshot of the result set and retrieves subsequent pages via a scroll_id.

Use search_after with a unique sort field to fetch the next page based on the previous page's last hit.

Both scroll and search_after provide millisecond‑level latency for sequential page access but do not support arbitrary page jumps.