Page 5 - Elasticsearch

JVM heap tuning in Elasticsearch is not a matter of "more heap is always better", it is a balance between the JVM heap for Java objects and the operating system file cache that Lucene uses for segment access. Setting the heap too large, or without regard for the 32 gigabyte compressed oops boundary, wastes performance and risks long garbage collection pauses right when load is highest.

An average swallows exactly the latency spikes that users actually feel, because a few very slow requests get masked by many fast ones. The percentiles aggregation in Elasticsearch instead computes distribution points like p50, p95 and p99, making it visible just how slow the slowest requests really are.

The terms aggregation is one of the most widely used Elasticsearch features, yet it quickly becomes a performance bottleneck at high field cardinality. The shard_size parameter, doc_count_error_upper_bound as an accuracy indicator, and eager global ordinals for precomputing expensive data structures together decide whether a facet query responds in single-digit or triple-digit milliseconds. This article shows how to deliberately tune terms aggregations at millions of unique values without losing sight of result quality.

A result list without highlighting forces users to scan every hit themselves for the term they searched for. Elasticsearch highlighting automatically marks relevant text passages in the search result, but the choice between Unified, Plain and FVH highlighter, along with fine-tuning fragment size, decides whether the highlighting is actually helpful or just distracting.

Anyone trying to export all buckets of a high cardinality field via a terms aggregation with a huge size value inevitably hits memory limits. The composite aggregation solves this problem with an after_key cursor that iterates page by page through any number of buckets, without ever holding more than one page in memory at a time. This article shows how to implement complete exports, reports and data pipeline iterations robustly and memory-efficiently with composite aggregation.

BM25 is the default scoring algorithm of Elasticsearch and OpenSearch, yet most developers only know the name, not the mechanics behind it. Term frequency, inverse document frequency, and field length normalization together determine why one document ranks higher than another, and anyone who understands these three factors can diagnose relevance problems on purpose instead of merely guessing.

Anyone using Elasticsearch only for full text search is leaving most of its analytical power on the table. Bucket aggregations group documents by field values, value ranges or time intervals, while metric aggregations compute concrete numbers such as average, sum or minimum from those groups. Only when both aggregation types work together do you get the dashboards, facets and reports that separate a production search application from a simple keyword search.

The Bool Query is the central tool of the Elasticsearch Query DSL for combining multiple conditions logically. Anyone who understands must, should, must_not, and filter, and knows when scoring context applies versus filter context, builds search queries that are both precise and fast, instead of throwing all clauses into one bucket and hoping for good results.

A sound Elasticsearch cluster architecture cleanly separates the control plane from the data plane: dedicated master nodes manage cluster state and shard allocation, while data nodes handle indexing and search under load. Ignoring this role separation risks split brain scenarios and cluster instability exactly when load is highest.

A new product attribute does not automatically end up where it is needed for search and filtering in the Elasticsearch index. Only a deliberate custom attribute mapping with dedicated FieldMapper classes ensures that searchable, filterable and the right field type fit together, instead of relying on Magento's default derivation.