What Is Elasticsearch?
Elasticsearch is a distributed, open-source search and analytics engine built on top of Apache Lucene. Unlike a relational database that scans rows to match a WHERE clause, Elasticsearch pre-builds an inverted index at write time, so a query for a word or phrase can jump straight to the matching documents instead of scanning everything. It stores data as JSON documents, distributes those documents across shards on multiple nodes, and can return relevance-ranked results across billions of documents in milliseconds.
Cricket analogy: Think of how Cricinfo's Statsguru instantly returns every ODI century Virat Kohli scored while chasing, rather than replaying every match ball by ball — that pre-built index of facts is exactly what Elasticsearch does for text.
Why Elasticsearch Exists: The Search Problem
Relational databases are optimized for structured, exact-match queries and transactional integrity, but they struggle with full-text search: ranking results by relevance, handling typos, tokenizing free text, and searching across millions of documents with sub-second latency. Elasticsearch was built to solve exactly this gap. It uses Lucene's inverted index under the hood, where every unique term maps to a list of documents containing it, plus scoring algorithms like BM25 to rank matches by relevance rather than just returning a boolean yes/no.
Cricket analogy: A SQL-style 'LIKE %century%' scan of commentary text is like manually rereading every over of a Test match to find when a century was scored, while Elasticsearch's inverted index is like an index card already sorted by keyword.
Core Concepts: Documents, Indices, and Distribution
In Elasticsearch, a document is a single JSON record (like one product or one log line), and an index is a collection of similar documents, roughly analogous to a database table. Every index is split into shards — independent Lucene indices — which are distributed across nodes in a cluster. This sharding is what lets Elasticsearch scale horizontally: adding more nodes lets you hold more data and parallelize more queries, and replica shards provide both fault tolerance and additional read throughput.
Cricket analogy: Splitting an IPL season's ball-by-ball data across shards is like splitting scoring duties across multiple official scorers at different venues, each handling their own matches, then combining the results at the end.
PUT /products
{
"mappings": {
"properties": {
"name": { "type": "text" },
"price": { "type": "float" },
"in_stock": { "type": "boolean" }
}
}
}
POST /products/_doc/1
{
"name": "Wireless Mechanical Keyboard",
"price": 79.99,
"in_stock": true
}
GET /products/_search
{
"query": {
"match": { "name": "mechanical keyboard" }
}
}Elasticsearch is built on Apache Lucene, but you rarely interact with Lucene directly — Elasticsearch wraps it with a distributed architecture, a REST API, and cluster coordination (via the Raft-like consensus in modern versions) so you get horizontal scalability and high availability out of the box.
Elasticsearch vs Traditional Databases
Elasticsearch is not a drop-in replacement for a relational database. It favors eventual consistency and availability over strict ACID transactions, has no native support for multi-document joins or foreign keys the way SQL does, and every field must be mapped (explicitly or via dynamic mapping) before it can be indexed the way you expect. It excels at full-text search, log and metrics analytics, and near-real-time aggregations over large datasets — use cases where a traditional RDBMS would require expensive LIKE queries or separate search infrastructure.
Cricket analogy: Using Elasticsearch as your system of record for bank-grade transactions is like relying on a scorer's quick tally for official BCCI records — useful for fast lookups, but not the authoritative ledger of truth.
Do not use Elasticsearch as your primary transactional data store. It lacks true multi-document ACID transactions and joins across indices are limited and expensive. The common pattern is to keep a source-of-truth database (PostgreSQL, MySQL, etc.) and sync relevant data into Elasticsearch for search and analytics.
- Elasticsearch is a distributed search and analytics engine built on Apache Lucene.
- It uses an inverted index to make full-text search fast, instead of scanning rows like a relational database.
- Documents are JSON records; indices group similar documents and are split into shards distributed across a cluster.
- BM25 relevance scoring ranks results instead of returning simple boolean matches.
- Sharding and replicas provide horizontal scalability and fault tolerance.
- Elasticsearch favors availability and eventual consistency over strict ACID transactions.
- It should complement, not replace, a transactional database as the system of record.
Practice what you learned
1. What underlying library does Elasticsearch build upon?
2. What data structure allows Elasticsearch to search text quickly instead of scanning every document?
3. What is a shard in Elasticsearch?
4. Which scoring algorithm does Elasticsearch use by default to rank search results?
5. Why shouldn't Elasticsearch typically be used as a primary transactional data store?
Was this page helpful?
You May Also Like
The ELK Stack Overview
A tour of Elasticsearch, Logstash, and Kibana (plus Beats) as a combined stack for ingesting, storing, and visualizing log and event data.
Indices, Documents, and Mappings
How Elasticsearch organizes data into indices and documents, and how mappings define the field types that control indexing and search behavior.
Installing and Running Elasticsearch
How to install, configure, and start a local Elasticsearch node or cluster, including key settings and common startup issues.
The Elasticsearch REST API
How to interact with Elasticsearch over HTTP: indexing, retrieving, searching, and managing documents and indices via the REST API.