Indices and Mappings

Elasticsearch's dynamic setting decides what happens to an unmapped field: true indexes it and adds it to the mapping, runtime adds it as a query-time field only, false ignores it but keeps it in _source, strict rejects the document.

text is analyzed into tokens for full-text search and cannot be sorted or aggregated by default. keyword stores the value verbatim as one term, which is what filters, sorts and aggregations need.

An index template attaches settings, mappings and aliases to any index whose name matches its index_patterns. It is applied once, at index creation time; indices that already exist keep whatever configuration they were created with.

An alias is a second name that points at one or more indices. Applications talk to the alias so the physical index behind it can be rebuilt, versioned and swapped atomically, with no client change and no downtime.

A rollover action lists conditions such as max_age, max_docs, max_primary_shard_size and max_size. ILM checks them on a periodic poll and rolls when any max condition is met, provided every min condition is also satisfied.

A multi-field indexes the same source value more than once under different mappings. The text half serves match queries, while title.keyword keeps the value verbatim for exact filters, sorting and aggregations — two capabilities one mapping cannot provide.

Exactly one composable index template is applied: the matching one with the highest priority. Elasticsearch refuses to store two templates whose index_patterns overlap at the same priority, so ties are prevented when you save the template rather than resolved at index creation.

A field's type and analyzer are baked into immutable Lucene segments when each document is indexed, so already-written data cannot be reinterpreted under a new type. Adding new fields is fine; changing an existing one requires a new index and a reindex.

Dynamic mapping turned unbounded data keys into permanent mapping entries and hit index.mapping.total_fields.limit, which defaults to 1000. Raising the limit is a stopgap; the fix is to stop the key space from becoming fields, using strict or scoped dynamic settings, templates, or a key/value structure.

Hot holds the actively written, most-queried indices on the fastest hardware. Warm holds recent read-only data on cheaper nodes, cold trades replicas for snapshot-backed storage, and frozen keeps only a local cache while the data itself lives in object storage.

dynamic_templates is an ordered list of rules in an Elasticsearch mapping. Each rule matches unmapped fields by detected JSON type, field name, or dotted path, and supplies the mapping to use. The first matching rule wins.

A runtime field is defined in the mapping or in a search request and evaluated per document at query time, usually from _source, with nothing written to the index. It gives schema-on-read: add, change or drop it instantly, and pay the cost on every query instead.

It becomes a text field with a keyword sub-field, because Elasticsearch's numeric_detection defaults to off. Date detection is on by default, so a date-looking string would instead be mapped as date — often the more dangerous surprise.

The value is skipped for that field: it is neither indexed nor written to doc_values, so term queries, sorts and aggregations never see it. It still appears in _source, which makes the loss easy to miss.

Component templates named in composed_of are merged in array order, each overriding the previous one on conflicts. The index template's own template block is applied last and beats them all, and anything supplied in the create-index request overrides even that.

Call POST _index_template/_simulate_index/<name>. Elasticsearch resolves that name against every stored template and returns the settings, mappings and aliases the index would actually receive, plus an overlapping list naming the templates that matched but lost on priority.

Use _update_by_query when the mapping change was legal in place — a new field or sub-field — and existing documents just need rewriting to pick it up. Use _reindex into a new index whenever the mapping itself could not be updated, such as a field type change.

Force merge rewrites an index into very few segments, which is expensive and only pays off once the data stops changing. A single huge segment is never merged again, so deleted documents inside it are never reclaimed while writes continue.

Call the ILM explain API for the index to see its current phase, action, step and any failure details, fix the underlying cause, then retry the policy for that index. Also confirm ILM itself is running cluster-wide.

Map it as keyword. Numeric types are optimized for range queries, keyword for exact-term lookups, and an identifier is only ever matched exactly. Numeric mapping also destroys leading zeros and invites meaningless arithmetic aggregations.

Set index: false on fields you only display or aggregate on, never search by; set doc_values: false on fields you only search or retrieve, never sort, aggregate or script on. Each removes one index structure to save disk and indexing time.

Composable templates win outright: if any composable index template matches a new index name, Elasticsearch ignores every legacy _template for that index. Legacy templates are deprecated, merge all matches by order, and cannot back data streams.

Pre-create the destination, then run the reindex asynchronously with wait_for_completion=false, parallelise it with slices, throttle it with requests_per_second, allow conflicts to proceed, and monitor the task id — rethrottling or cancelling it if live traffic suffers.

Build a new index with the corrected mapping beside the old one, reindex into it, keep it current with dual writes or repeated timestamp catch-up passes, verify counts and queries, then move the alias in one atomic call and keep the old index for rollback.

Work backwards from query patterns: keep a few days hot on fast disk, weeks warm and force-merged, months as snapshot-backed cold or frozen indices where object storage carries the bulk, and delete on schedule with a snapshot guard.

Split the document into a declared core that is strictly mapped and a free-form subtree that is not allowed to mint unbounded fields. Isolate tenants across indices so one tenant's key space cannot poison a shared mapping, and enforce field-count budgets with alerting.

Layer a small number of semantic component templates - platform defaults, shared schema, per-team fields, an override slot - and give each family one narrow index template with a priority from a documented band. Keep all of it in version control and gate changes on simulated output.

Use flattened when an object's keys are open-ended and would otherwise create thousands of mappings. The whole object becomes one field whose leaf values are indexed as keywords — cheap and bounded, but with no per-key types and no full-text analysis.

Treat every index as a disposable, versioned artifact behind an alias, keep the authoritative data outside Elasticsearch so any index can be rebuilt from source, automate create-reindex-verify-swap as one pipeline, and budget standing capacity for rebuilds.