Page 2 - Elasticsearch

A rolling upgrade updates an Elasticsearch or OpenSearch cluster node by node, while the cluster keeps serving requests the entire time. Anyone who correctly disables shard allocation before every node restart and respects the version compatibility rules between major versions can move production clusters to a new version without any planned downtime.

As soon as a product has multiple variants with their own size, color and price, classic aggregation fails silently and miscounts. The nested aggregation operates on a separate, isolated Lucene index inside the parent document, which yields correct facets at variant level. With reverse_nested you can additionally jump back into the parent context to build facets that correctly connect both variant and product level.

Anyone who creates new indices for logs, metrics or orders every day knows the problem: without a central definition, mappings and settings drift apart until queries return inconsistent results. Composable index templates and reusable component templates solve exactly that by defining mapping rules once and applying them automatically to every new index that matches a naming pattern.

A type-ahead field that fires a new query at Elasticsearch on every keystroke can put a cluster under real load long before the actual result index is even large. search_as_you_type provides the data structure for performant prefix matching, but only the right combination of query design, shard distribution and frontend debouncing turns it into a search that stays stable under load.

Magento's default relevance treats every attribute by the same rules, regardless of whether a search request looks for SKU, brand, or description. Deliberately controlling search relevance via search weight, custom query builders, and function score boosting brings the products that actually matter for a given shop to the top.

A search that finds "laptop" but returns nothing for "notebook", or that treats "running" and "ran" as completely different words, loses users before the first click. Synonyms and stemming solve exactly this problem when combined correctly in the analyzer, but the details of synonym_graph, stemmer type and language selection decide whether the search becomes more precise or just fuzzier.

"Why does product B rank above product A, even though A is the better match?" is one of the most common questions in day-to-day relevance work, and without a systematic tool the answer remains guesswork. The Explain API exposes exactly which individual terms, weights and boosts make up a BM25 score, turning scoring debugging from guessing into analysis.

The Magento CatalogSearch architecture looks like a black box from the outside: you update an attribute, wait for the reindex, and hope search returns the right result. Understanding how the indexer, fulltext scope tables and the Elasticsearch adapter work together lets you debug, extend and fix performance issues at the right place instead of chasing symptoms.

One store view per language is not enough to truly run clean multilingual search in Magento. Only store-view-based index naming combined with language-specific Elasticsearch analyzers prevents German compound words from being split incorrectly or English stemming rules from being applied to French text.

Every filter option in Magento layered navigation, from brand selection to the price slider, is the result of an Elasticsearch aggregation computed in the background alongside the actual search request. Understanding how terms and range aggregations are built lets you add your own facets and fix navigation performance issues at the right place.