Scaling data / Intermediate / 5 min
Elasticsearch: how an inverted index finds things
Type a search over a product catalogue. See terms, stemming and posting lists find what SQL LIKE misses, while reading far less.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- Elasticsearch analyses text into terms and keeps an inverted index from each term to the documents that contain it, then ranks matches by relevance.
- Why it matters
- Users type loose words, plurals and typos, and a database LIKE scan is both slow and too literal for that.
- The trade-off
- Search is fast and forgiving, but the index is a second copy that lags the database and must be kept in sync.
- Say it in an interview
- "Primary data in Postgres, change events through Kafka into Elasticsearch, analyzers per language, BM25 ranking, and the app queries the search cluster for search boxes only."
Check yourself
What is an inverted index?
Answer: A map from each term to the list of documents that contain it. A query reads only the lists for its terms instead of scanning every document.
Why does a search for "run shoe" find "Running shoes for men"?
Answer: The analyzer stems both the titles and the query, so both become "run" and "shoe". Index-time and query-time analysis must match; that is why the analyzer choice matters so much.
Why is SQL LIKE '%phrase%' slow on a big table?
Answer: A leading wildcard cannot use a normal index, so every row is read. The database has to check each row; full-text indexes avoid that.