Basic mapping tells Elasticsearch what a field is. These concepts control how mappings scale, adapt, and stay maintainable as your schema grows.

An index template is a saved configuration (mappings, settings, aliases) that gets automatically applied whenever a new index matching a name pattern is created — useful for daily or monthly indices like logs-2026-09 that all need the same structure.

A dynamic template lets you define custom rules for how automatically-detected fields should be mapped — for example, “any field ending in _id should be mapped as a keyword,” instead of relying on Elasticsearch’s default guesses.

Multi-fields let a single field be indexed multiple ways at once — for example, a “title” field indexed as both text (for full-text search) and keyword (for exact matching and sorting) under the same field name.

The object type stores a JSON object with nested fields, but internally Elasticsearch flattens those fields, which means relationships between values inside array items can be lost during search.

The nested type stores each object in an array as a hidden, separate document internally, preserving the relationships between fields within each object — critical when you need to search “an item where color is red AND size is large” within an array of items.

A runtime field is calculated at query time instead of being stored in the index, giving you flexibility to add new fields to existing data without reindexing — at the cost of slightly slower queries compared to indexed fields.

An index alias is a secondary name that can point to one or more real indices, letting applications query a stable alias name (like “products”) while the underlying index changes behind the scenes, such as during reindexing.

Beyond match and term queries, these query types handle the messier, real-world search requirements production systems actually need.

A multi-match query searches the same text across several fields at once — for example, checking both “title” and “description” for a keyword, instead of writing a separate match query for each field.

A fuzzy query matches terms that are similar but not identical to the search term, tolerating typos — searching for “elasticsarch” can still match documents containing “elasticsearch.”

A wildcard query matches patterns using special characters, like * for any number of characters — for example, lap* would match “laptop” and “lapdog.” It’s flexible but can be slow on large datasets.

A range query finds documents where a numeric or date field falls within a given range — for example, products priced between $50 and $200, or orders placed in the last 7 days.

A nested query is required to correctly search fields mapped as the nested type, since it searches within each nested object as its own unit rather than treating the array as flattened data.

A function score query lets you modify the relevance score of results using custom logic — for example, boosting newer products, or ranking items higher if they have more reviews, on top of normal text relevance.

Boosting increases the importance of a specific field or clause in a query — for example, giving matches in the “title” field twice the weight of matches in the “description” field when calculating relevance.

The minimum_should_match parameter controls how many “should” clauses in a bool query must match for a document to be considered a hit — useful for tuning how strict or lenient a multi-word search is.

Understanding why one result ranks above another is a core intermediate skill — this is where Elasticsearch’s ranking math starts to matter.

BM25 is the default relevance-scoring algorithm Elasticsearch uses. It considers how often a search term appears in a document, how rare that term is across the whole index, and how long the document is, to calculate a relevance score.

TF-IDF (Term Frequency–Inverse Document Frequency) is an older relevance formula that BM25 evolved from — it rewards terms that appear often in a document but rarely across the whole dataset, since rare terms tend to be more meaningful.

Field-level boosting assigns different importance weights to different fields during search, such as making title matches count more than body-text matches when calculating the overall relevance score.

A script score lets you write custom scoring logic using a scripting language, giving full control over how relevance is calculated — for example, combining text relevance with a popularity metric stored in another field.

The Explain API shows a detailed, step-by-step breakdown of exactly how a document’s relevance score was calculated, which is invaluable for debugging why a certain result ranked higher or lower than expected.

Custom text analysis is what makes search feel tailored to your specific data, rather than relying on Elasticsearch’s generic defaults.

A custom analyzer is one you build yourself by combining a specific tokenizer with specific token filters, instead of using the built-in Standard Analyzer — useful when your data has special formatting needs, like product SKUs or hashtags.

An n-gram tokenizer breaks text into small overlapping chunks of characters (like “sea,” “ear,” “arc” from “search”) which enables partial-word and substring matching, at the cost of a larger index.

An edge n-gram generates chunks starting only from the beginning of a word (like “s,” “se,” “sea,” “sear” from “search”), which is what powers “search-as-you-type” style autocomplete suggestions.

A synonym filter lets you define words that should be treated as equivalent during search — for example, mapping “laptop” and “notebook” to match each other, even though they’re different words.

A language analyzer applies language-specific rules for stemming, stop words, and grammar — for example, the English analyzer knows that “running” and “runs” share the same root, while a French analyzer handles French grammar rules instead.

A normalizer applies simple text transformations (like lowercasing) to keyword fields, without full tokenization — useful for making exact-match fields like emails or tags case-insensitive while still supporting sorting and aggregations.

Beyond simple grouping, intermediate aggregations let you build multi-level analytics and derive new metrics from existing aggregation results.

A sub-aggregation is an aggregation nested inside another aggregation’s buckets — for example, grouping orders by month (bucket aggregation), then calculating the average order value within each month (metric sub-aggregation).

A pipeline aggregation takes the output of other aggregations as its input, rather than working directly on documents — used for things like calculating a moving average or the cumulative sum across time-based buckets.

A composite aggregation is designed for paginating through a very large number of unique bucket combinations efficiently, which regular bucket aggregations struggle to do at scale.

A cardinality aggregation estimates the number of distinct values in a field — for example, roughly how many unique users visited a website — using an efficient approximate algorithm rather than counting exactly, which would be far slower at scale.

A percentiles aggregation calculates values at specific percentile points — for example, the 95th percentile response time tells you the value below which 95% of requests fall, commonly used for performance monitoring.

Running Elasticsearch in production means actively managing indices over time, not just creating them once.

ILM automates how an index moves through stages over its lifetime — hot (actively written), warm (read-only but still queried), cold (rarely accessed), and delete — reducing manual maintenance for time-series data like logs.

Rollover automatically creates a new index once the current one reaches a certain size, document count, or age, which is commonly used with ILM for continuously growing data like daily logs.

The Shrink API reduces the number of primary shards in an index, useful for consolidating an over-sharded older index once it no longer receives new writes and doesn’t need as much parallelism.

Force merge manually triggers the merging of an index’s underlying segments into fewer, larger ones, which can improve search performance on read-only indices, though it’s an expensive operation not meant for actively-written indices.

Snapshot and restore is Elasticsearch’s backup mechanism — snapshots capture the state of indices at a point in time to external storage, and restore brings that data back, which is essential for disaster recovery.

Shard allocation awareness tells Elasticsearch about the physical or logical grouping of nodes (like availability zones), so it can intelligently spread primary and replica shards to avoid losing all copies of data in a single outage.

These are the levers intermediate users learn to pull when indexing or search performance needs improvement.

The refresh interval controls how often newly indexed documents become searchable. A shorter interval means near-real-time search but more overhead; a longer interval reduces overhead but delays visibility of new data.

Elasticsearch stores data in small immutable files called segments, and merging combines smaller segments into larger ones in the background, which keeps searches fast as data grows and deletes accumulate.

The query cache stores the results of frequently used filter clauses, so repeated queries with the same filters don’t have to be recalculated from scratch every time.

The request cache stores the full results of aggregation-heavy searches that return no individual document hits, which is common for dashboard-style queries that get run repeatedly with the same parameters.

A circuit breaker is a safety mechanism that stops an operation before it uses so much memory that it could crash a node, protecting overall cluster stability at the cost of occasionally rejecting an overly expensive request.

Bulk indexing tuning refers to adjusting batch sizes, concurrency, and refresh settings when loading large volumes of data, to maximize indexing throughput without overwhelming the cluster.

The slow log records queries and indexing operations that take longer than a configured threshold, helping operators identify and diagnose performance bottlenecks in real production traffic.

Once Elasticsearch holds real data, securing access to it becomes just as important as querying it correctly.

RBAC lets administrators define roles with specific permissions (like read-only access to one index) and assign those roles to users, rather than giving everyone full cluster access.

An API key is a credential applications can use to authenticate with Elasticsearch, often scoped to specific permissions and given an expiration, which is safer than sharing a full user’s username and password.

TLS encrypts data moving between nodes in a cluster, and between clients and the cluster, preventing sensitive data from being readable if intercepted over the network.

Audit logging records security-relevant events — like login attempts and access to specific indices — which is often required for compliance and helps investigate suspicious activity after the fact.

A snapshot repository is the external storage location (such as a cloud storage bucket) registered with Elasticsearch, where snapshot backups are actually saved and later restored from.

Field-level security restricts which specific fields within a document a user or role is allowed to see, useful when different teams need access to the same index but not to every sensitive field within it.

Use nested type whenever you need to query relationships between fields inside array items accurately — for example, matching an item that is both “color: red” and “size: large” together, rather than matching either condition against any item in the array.

BM25 scoring depends partly on statistics across the whole index (like how common a term is), so scores can shift slightly as the overall dataset composition changes, even for the same document.

You can, but very frequent refreshing increases resource usage and can hurt indexing throughput, so most production systems balance near-real-time visibility with a slightly longer interval, often one second or more.

ILM automates the entire lifecycle — moving, shrinking, and deleting indices based on rules — while manual deletion requires someone to remember and execute those steps, which doesn’t scale well for large time-series deployments.

It’s still strongly recommended. Internal networks can still be compromised, and Elasticsearch’s own default security settings assume production deployments should have authentication and encryption enabled.