Before touching any query, you need the basic vocabulary — what Elasticsearch actually is, and the handful of building blocks every other concept is built on.

Elasticsearch is a search and analytics engine. It stores data in a way that makes searching through huge amounts of text or numbers extremely fast, even across millions or billions of records. Think of it as a super-powered filing system built specifically to answer the question “find me everything that matches this” in milliseconds.

A search engine, in the Elasticsearch sense, is software that takes a query (what you’re looking for) and quickly returns matching results from a large collection of stored data, ranked by how relevant each result is.

A document is a single unit of data in Elasticsearch, stored in JSON format (a simple text format made of key-value pairs). A document could represent one product, one log entry, one blog post, or one user profile.

An index is a collection of related documents, similar to a table in a traditional database. For example, you might have a “products” index holding all your product documents and a separate “orders” index for order documents.

A node is a single running instance of Elasticsearch — essentially one server (or one process) that stores data and helps process search requests. A real deployment usually runs several nodes working together.

A cluster is a group of one or more nodes working together, sharing the overall data and workload. From the outside, a cluster behaves like one unified system, even though it may be made of dozens of individual nodes.

A shard is a smaller piece of an index. When an index gets too large to fit comfortably on one node, Elasticsearch splits it into multiple shards and spreads them across different nodes, so no single machine has to hold everything.

A replica shard is an exact copy of a primary shard, kept on a different node. Replicas exist for two reasons: if a node goes down, the data isn’t lost, and replicas can also help handle more search traffic at once.

JSON (JavaScript Object Notation) is a lightweight text format for representing data as key-value pairs, like {"name": "Laptop", "price": 999}. Elasticsearch stores and returns almost everything in this format.

A RESTful API is a way of talking to Elasticsearch using standard web requests (like the ones your browser sends), such as GET to read data, POST to create it, and DELETE to remove it. This means you can interact with Elasticsearch using simple HTTP calls, without any special software.

flowchart TB
    Client["Client / Application"] -->|HTTP REST Request| Coord["Coordinating Node"]
    Coord --> N1["Node 1"]
    Coord --> N2["Node 2"]
    Coord --> N3["Node 3"]
    N1 --> S1["Primary Shard 0"]
    N1 --> R2["Replica Shard 1"]
    N2 --> S2["Primary Shard 1"]
    N2 --> R1["Replica Shard 0"]
    N3 --> S3["Primary Shard 2"]
    N3 --> R3["Replica Shard 2"]
    

Once you know what documents and indices are, the next question is: how does Elasticsearch know what kind of data is inside each document?

Mapping is the schema of an index — it defines what fields exist in the documents and what data type each field holds (text, number, date, and so on). It is similar to defining column types in a database table.

A field is a single named piece of data inside a document, similar to a column in a spreadsheet. For example, a product document might have fields called “name,” “price,” and “in_stock.”

A data type tells Elasticsearch what kind of value a field holds — common types include text (for full-text search), keyword (for exact matching, like tags or IDs), integer/float (for numbers), and date (for timestamps).

Dynamic mapping is a feature where Elasticsearch automatically detects and creates field types for you when you add a new document, without you having to define the mapping upfront. It’s convenient for beginners, though production systems often prefer defining mappings explicitly.

The _source field is a special metadata field that stores the original JSON document exactly as it was submitted. When you search and get results back, Elasticsearch usually returns the _source so you see your original data.

The _id field is a unique identifier for each document within an index, similar to a primary key in a database. You can supply your own ID or let Elasticsearch generate one automatically.

The _index field simply tells you which index a particular document belongs to — useful when you’re searching across multiple indices at once.

Metadata fields are the special, built-in fields (like _id, _index, and _source) that Elasticsearch attaches to every document automatically, separate from the actual data fields you define.

CRUD stands for Create, Read, Update, Delete — the four basic actions you can perform on any document.

“Indexing” in Elasticsearch simply means adding (or saving) a document into an index. It’s the equivalent of “inserting a row” in a traditional database.

A GET request retrieves a single document from an index using its unique _id, similar to looking up a specific record by its ID.

An update operation modifies an existing document’s fields without needing to resend the entire document. Internally, Elasticsearch actually replaces the whole document behind the scenes, but from the user’s side it feels like a partial edit.

A delete operation removes a document from an index permanently, identified by its _id.

The Bulk API lets you perform many index, update, or delete operations in a single request instead of sending them one at a time, which is much faster when working with large amounts of data.

Reindexing means copying documents from one index into another, often used when you need to change a mapping — since mappings can’t easily be changed after data is already stored, you create a new index with the correct mapping and reindex the data into it.

Every document in Elasticsearch has an internal version number that increases each time it’s updated, which helps prevent conflicting changes from accidentally overwriting each other.

Searching is the heart of Elasticsearch. This chapter covers the beginner vocabulary for asking Elasticsearch to find something.

Query DSL (Domain Specific Language) is the JSON-based language you use to describe searches to Elasticsearch — essentially, a structured way of writing “find documents where…” as a JSON object.

A match query performs a full-text search, looking for documents where a text field contains the words you searched for — it’s the everyday “search box” style of querying.

A term query looks for an exact match of a value, without any text analysis — commonly used on keyword fields, like finding all documents where a status field exactly equals “shipped.”

A match_all query simply returns every document in an index, with no filtering — useful for quickly checking what data exists.

A bool query lets you combine multiple conditions together using logical clauses like “must,” “should,” and “must not” — for example, “must contain ‘laptop’ and must not be out of stock.”

Query context calculates how relevant a result is (a relevance score), while filter context simply checks yes-or-no conditions (like “in stock: true”) without affecting the score, and is generally faster because it can be cached.

The _score is a number Elasticsearch assigns to each search result, indicating how well it matches your query. Higher scores mean better matches, and results are typically sorted by score, highest first.

Pagination lets you retrieve search results in smaller chunks (pages) instead of all at once, using “from” (how many results to skip) and “size” (how many results to return) parameters.

These are the concepts that explain why Elasticsearch is so fast, and why text search behaves differently from an exact database lookup.

An inverted index is the core data structure that makes Elasticsearch fast — instead of scanning every document to find a word, it keeps a map of “this word appears in these documents,” so lookups are almost instant.

An analyzer is a process that breaks text into smaller searchable pieces before storing it. It typically involves lowercasing text, splitting it into words, and removing unnecessary words.

A tokenizer is the part of the analyzer that splits a block of text into individual words or “tokens” — for example, turning “fast search engine” into three separate tokens: “fast,” “search,” “engine.”

A token filter modifies tokens after they’ve been split — for example, converting all letters to lowercase, or removing common words, so that “Search” and “search” are treated as the same word.

The Standard Analyzer is the default analyzer Elasticsearch uses if you don’t specify one — it lowercases text and splits it into words based on typical word boundaries like spaces and punctuation.

Stop words are extremely common words like “the,” “is,” and “and” that carry little search meaning on their own. Some analyzers remove them to focus on more meaningful words.

Stemming reduces words to their base or root form, so that “running,” “runs,” and “ran” can all match a search for “run.” This helps searches feel smarter and more forgiving.

Full-text search looks for meaningful word matches inside a block of text (like searching an article for a topic), while an exact match checks whether a value is precisely identical (like matching an email address or a status code).

A production Elasticsearch cluster is made of nodes that each play a different role, working together behind a single unified interface.

A master node is responsible for cluster-wide management tasks — like tracking which nodes exist, deciding where shards should live, and keeping the overall cluster state consistent.

A data node is where the actual document data and shards are stored, and where searches and indexing operations are physically performed.

A coordinating node receives client requests, forwards them to the relevant data nodes, gathers the results, and sends a single combined response back — acting like a traffic director for search requests.

An ingest node can pre-process documents (like extracting fields or transforming values) before they are actually stored, similar to a lightweight step in a data pipeline.

Cluster health is a simple status indicator: green means all shards (primary and replica) are healthy and available, yellow means primary shards are fine but some replicas are missing, and red means some primary shard data is unavailable.

Node discovery is the process by which nodes find each other and agree to form a single cluster when they start up, without needing to be manually connected one by one.

A sharding strategy is the plan for how many shards an index should be split into, based on expected data size and search load — too few shards can limit scaling, while too many can add unnecessary overhead.

Beyond simple search, Elasticsearch can also summarize and analyze data — this is called aggregation.

An aggregation is a way of summarizing data returned by a query — like calculating an average, finding a maximum value, or grouping results into categories, similar to “GROUP BY” in traditional databases.

A metric aggregation calculates a single numeric value from your data, such as an average price, a total sum, or the minimum and maximum values in a field.

A bucket aggregation groups documents into categories (“buckets”) based on shared criteria — for example, grouping products by category, or grouping orders by the month they were placed.

A terms aggregation is a specific type of bucket aggregation that groups documents by the distinct values of a field — for example, showing how many products exist for each brand.

A histogram aggregation groups numeric or date values into evenly sized ranges — for example, grouping orders into buckets of “$0–50,” “$50–100,” and so on.

Elasticsearch is rarely used entirely alone — it’s usually paired with a small family of companion tools.

Kibana is a visualization and dashboard tool that connects to Elasticsearch, letting you explore data, build charts, and create dashboards through a web interface instead of writing raw queries.

Logstash is a data-processing pipeline tool that can collect data from many sources, transform it, and send it into Elasticsearch for storage and search.

Beats are lightweight data shippers — small programs installed on servers to collect specific types of data (like log files or system metrics) and forward them toward Elasticsearch or Logstash.

The ELK Stack refers to the combination of Elasticsearch, Logstash, and Kibana used together to collect, store, search, and visualize data, commonly used for log and monitoring use cases.

Elastic Cloud is a fully managed, hosted version of Elasticsearch and its ecosystem, run by the company behind Elasticsearch, so you don’t have to install or maintain the servers yourself.

Not in the traditional sense. Elasticsearch is a search and analytics engine built for extremely fast text search and aggregation, not a general-purpose transactional database. Many teams use it alongside a primary database rather than instead of one.

No — Elasticsearch primarily uses its own JSON-based Query DSL, though it does also offer an SQL-like interface for people already comfortable with SQL.

Conceptually they’re similar — both group related records together — but an index in Elasticsearch is optimized for fast searching across text and combines automatically with concepts like shards, replicas, and analyzers that traditional tables don’t have.

Splitting data into shards allows Elasticsearch to spread both storage and search workload across multiple machines, which is what allows it to scale to very large datasets.

Yes. Elasticsearch works perfectly well on its own; Kibana and Logstash are optional companion tools that make visualization and data ingestion easier, not requirements.