Page 4 - Elasticsearch

Correct shard sizing decides whether an Elasticsearch index runs stable for years or suffers from heap pressure and slow cluster state management after just a few months. Too many small shards waste resources on metadata overhead, too few large shards prevent parallelization. This article shows how to determine the target size per shard and rebuild existing indices without downtime.

An Elasticsearch index without deliberate mapping usually works fine on day one and turns into a construction site the moment the first production search problem shows up. Teams who clarify field types, immutability and analyzer assignment before indexing save themselves painful reindexing and inconsistent search results later.

Match query and term query look interchangeable at first glance, but they work fundamentally differently. The match query analyzes text before comparing it, the term query compares exactly and without any filtering. Anyone who ignores this difference gets empty result lists on text fields and wrongly permissive hits on keyword fields, without understanding why.

When search in the store returns wrong or missing results, guessing rarely helps. Systematic search debugging starts by capturing the actual Elasticsearch query Magento generates, running that query directly against the cluster, and reliably separating whether the problem lies in Magento's logic or in the Elasticsearch index itself. This article walks through the methodology step by step.

Solid cluster health monitoring does not stop at the simple green/yellow/red status, it watches the metrics that actually indicate a brewing problem: unassigned shards, growing heap pressure and rejected requests from full thread pool queues. This article shows which signals really deserve an alert and how to monitor them reliably.

Dynamic mapping feels convenient until a single index accumulates thousands of fields and the cluster state grows so large that every mapping change becomes noticeably slower. Mapping explosion usually creeps in from key value style data structures that generate new fields without limit, and it can be reliably prevented with clear limits, targeted dynamic:false and the flattened data type, before it turns into a production problem.

Full text search, exact filtering, sorting and aggregation place conflicting demands on the very same field value. Multi-fields resolve that conflict by indexing one value in several parallel representations at once, so each query type uses the representation it needs without duplicating any data.

Anyone planning a new search solution for a Magento shop faces a fundamental decision: self-hosted Elasticsearch or OpenSearch with full control and operational overhead, or a SaaS search solution like Algolia or Klevu with usage-based cost and less infrastructure work. This article compares cost, control, features and integration effort of all three options concretely for Magento merchants.

Legacy shops built on Magento 1 or an early Magento 2 base often still run on Solr as their search technology, even though Solr has not been supported since Magento 2.4. The search migration from Solr to Elasticsearch or OpenSearch touches schema, reindex process, and storefront behavior alike. This article delivers a complete checklist, a schema mapping, and a rollback plan for a low-risk switch.

Faceted navigation lives on terms aggregations over product attributes, but those aggregations are only as fast as the mapping underneath them. Index attributes as an analyzed text type instead of keyword, and you get fragmented filter values, duplicate facets and aggregations that burn unnecessary memory and compute time on every category page.