Performance Analysis of Elasticsearch Queries: Lucene Internals and Benchmark Results

Elasticsearch is a popular distributed search system that offers powerful and easy-to-use query and analytics capabilities, including full‑text, fuzzy, multi‑condition, and geo queries, as well as aggregation functions. Analyzing its query performance is complex because many factors—such as hardware, configuration, and cluster size—affect it.

Lucene Query Fundamentals – Elasticsearch relies on Lucene, so Lucene's query performance determines Elasticsearch's performance. Key Lucene data structures include:

FST: stores the term dictionary and enables term, range, prefix, and wildcard queries.

Inverted lists (skip‑list): store ordered docId lists for each term.

BKD‑Tree: a multidimensional index for numeric and geo points.

DocValues: column‑oriented storage based on docId, improving sorting and aggregation.

Combining Query Results – For composite queries, Lucene must merge the results of individual conditions. Intersection of N inverted lists uses skip‑lists to jump over irrelevant docIds, while union can be handled by a priority queue (min‑heap) for few lists or by merging into a sorted array or BitSet for many lists.

BKD‑Tree results are unordered; they must be sorted or converted to a BitSet before merging with other results.

Query Order Optimization – Lucene estimates the cost of each sub‑query and executes cheaper ones first, reducing the amount of data processed in later stages.

Result Sorting – By default, Lucene sorts by score, but custom sort fields are supported. Sorting only builds a heap for the top (size + offset) documents, so its impact depends on those parameters and the cost of reading DocValues.

Performance Benchmarks

Single‑Term Query – A request filtering on Tag1="a" (≈5.2 M matching docs) took 233 ms, indicating a scanning speed of roughly ten million docIds per second per CPU core. A smaller inverted list (≈10 K docs) took 3 ms.

Term Combination (Intersection) – Combining a 5 M and a 10 K inverted list (must clause) took 21 ms, mainly due to skip‑list processing. The same terms with a should clause (union) took 393 ms.

String Range Query (FST) – Scanning a UUID range (0–8) over 10 M docs took 3001 ms, while a narrower range (a–b) took 379 ms, showing that FST scans are about ten times slower than inverted‑list scans.

String Range + Term Queries – Adding two term filters to the large range query resulted in 2849 ms, dominated by the FST scan and subsequent BitSet construction.

Numeric Range Query (BKD‑Tree) – Searching a numeric range covering ~5 M docs took 567 ms, demonstrating good BKD‑Tree performance.

Numeric Range + Term Queries – Adding two term filters reduced the total time to 27 ms because Lucene first intersected the small term result sets (≈5 K docs) and then applied the numeric filter using DocValues, avoiding a full BKD‑Tree scan.

Key Conclusions

Scanning more docs degrades performance proportionally.

Inverted‑list scans can reach tens of millions of docIds per second; for numeric fields, storing them as strings can be beneficial.

Skip‑list efficiency depends on the length of the shortest list and the cost of each skip.

FST‑based string queries are significantly slower than inverted‑list queries.

BKD‑Tree numeric range queries are fast, but merging with other results may require BitSet construction; Lucene’s IndexOrDocValuesQuery can optimize such cases.

Future work will explore early‑termination techniques to further improve query performance.