Elasticsearch

Elasticsearch mappings cannot be fundamentally changed once an index exists, a new data type or a different analyzer setup always requires a brand new index. Zero-downtime reindexing combines the _reindex API with a write alias and a read alias, so clients keep addressing the same name forever while data is copied in the background and finally switched over atomically to the new index.

Every full text search in Elasticsearch stands or falls with the analyzer that breaks text into comparable tokens at index time and at search time. Understanding character filters, tokenizers and token filters as a pipeline lets you build your own analyzers and understand why a search returns hits, or does not.

Since Elastic's license change in January 2021 and the subsequent fork into OpenSearch, both search engines have been evolving technically and legally in different directions. This article puts the fork's history into context, shows the concrete feature divergence, and provides criteria for a well founded migration decision between Elasticsearch and OpenSearch.

Elasticsearch's standard analyzer treats every language the same and thereby ignores word stems, stopwords and special characters that differ completely between German, French or English. A custom analyzer per language, combined with a per-field-per-language mapping strategy, turns a generic full text search into one that actually returns the right hits in every shop language.

Magento stores search synonyms per store view in a dedicated database table and translates them into an Elasticsearch synonym filter during index building. Anyone who does not understand this mechanism ends up maintaining synonyms that never take effect, either because a reindex is missing or because they hit the wrong store view. This article walks through the complete path from the admin interface to the analyzer configuration inside the Elasticsearch index.

Runtime fields compute a field at query time with a Painless script, instead of storing it fixed in the mapping at index time. That lets you try out new analytics ideas immediately, without reindexing billions of documents before knowing whether the idea is even worthwhile.

Index aliases are more than an alternate name for an index: used strategically they become the central versioning tool that permanently decouples clients from physical index names. Between filtered aliases for multi-tenancy, routing aliases for shard optimization and the write index flag for controlled rollovers, an architecture emerges where indices can be swapped out without a single application ever touching its configuration.

Pure BM25 scoring only knows text relevance, no business goals. The Function Score Query closes this gap by combining the textual score with additional factors such as sales figures, stock level, or freshness. Anyone who masters field_value_factor and decay functions can steer search results deliberately by business logic without sacrificing textual relevance.

An exact count of unique values across billions of documents would be nearly impossible to justify in terms of memory. The cardinality aggregation solves this problem with the HyperLogLog++ algorithm, which approximates the number of unique values with constant, very small memory usage instead of remembering every value individually. The precision_threshold parameter decides how tightly accuracy and memory usage are coupled, and this article shows when the resulting error rate is completely unproblematic from a business perspective.

A hot-warm-cold architecture distributes data by age across hardware of varying performance and cost, driven by automated index lifecycle management policies. Fresh, frequently queried data sits on fast SSD hardware, older data automatically migrates to cheaper nodes, without anyone intervening manually.