Lesson 0009 · Consolidation

Interleaved review

No new material — mixed retrieval across all eight lessons, to make it stick.

~15 minInterleaved quiz + free recallAll refs & lessons

Why this session is different

The other lessons taught one topic each — easy to feel fluent. This one interleaves: questions jump between relevance, internals, the DSL, and ops in no fixed order, and none are labelled with their topic. That difficulty is the point — effortful, mixed retrieval is what converts short-term fluency into long-term storage strength. Answer every item from memory before checking. Note anything you miss; the explanation links back to the lesson to revisit.

Part 1 — Interleaved quiz

Twelve questions, deliberately shuffled across all eight lessons. Feedback is immediate.

A term query on a text field finds nothing because:

term isn't analyzed, but the field was — so literal "Elasticsearch" ≠ indexed elasticsearch. Lesson 0003.

A single shard runs a given search on:

One CPU thread per shard per search — fan across thousands of shards and the search thread pool is exhausted. Lesson 0008.

BM25's k1 parameter controls the:

k1 sets how fast repeated terms saturate; b controls length normalization; IDF has no knob. Lesson 0002.

With a must present, adding a should clause:

With a must/filter present, minimum_should_match defaults to 0 — should only boosts scores, never filters. Lesson 0006.

A term's document frequency is physically:

df = number of docs containing the term = the length of its postings list = IDF's n. Lesson 0004.

Which pair of clauses runs in filter context?

filter and must_not — unscored and cacheable. must/should are query context (scored). Lesson 0001.

Deleting a document at first only:

Segments are immutable — the doc is marked in a .del file and purged only at merge. Lesson 0005.

A terms aggregation should target:

Aggregate on keyword (one exact term); text is tokenized and disabled for aggs by default. Lesson 0007.

IDF gives the most weight to a term that is:

IDF rewards rarity across documents (small n). Within-doc density is TF; position doesn't affect BM25. Lesson 0002.

A newly indexed document becomes searchable after:

Refresh (default ~1s) turns the in-memory buffer into a searchable segment — the “near real-time” story. Lesson 0005.

Over-sharding most directly drains a node's:

Each tiny shard costs heap (segment metadata) and a search thread; too many exhausts both. It doesn't change scoring or analysis. Lesson 0008.

A bool query's final _score is:

More-matches-is-better: BM25 scores of matching must/should clauses are added. Lesson 0006.

Part 2 — Free recall (the real test)

Multiple choice lets you recognize; these make you produce. Say (or write) each answer fully from memory, then expand to check. Storage strength is built here.

1 · Trace match: "Brown Foxes" on a text field, from raw string to ranked hits. Name every stage.
"Brown Foxes" → analyse → terms [brown, fox]seek the sorted term dictionary (binary search) → read + merge the postings lists → candidate docs → BM25 score (per segment, per shard, then combined) → ranked hits

The backbone answer to “how does a full-text query become a ranked result set?” — analysis (0003) → inverted index (0004) → BM25 (0002), fanned across segments (0005) and shards (0008).

2 · Design the bool: full-text relevance on title, only status: published, only year ≥ 2020, exclude anything titled “deprecated”, and boost docs also mentioning “guide”. Which clause holds each?

Placement follows the two columns from 0006: does it score? does it cache?

3 · You expect ~300 GB of data. How many primary shards, roughly — and name two symptoms if you instead made 600 tiny shards?

ceil(300 / ~40 GB) ≈ 8 primaries (target 10–50 GB/shard, <200M docs/shard). Over-sharding symptoms: heap pressure from per-shard segment metadata, search-thread-pool exhaustion, cluster-state bloat, slow searches / instability. Lesson 0008.

4 · Why can the same document get a slightly different _score on different shards — and what connects that to why a terms aggregation's counts are “approximate”?

IDF uses per-shard N and n, so term stats differ by shard (fix: dfs_query_then_fetch). Same root cause for aggs: each shard computes its own top buckets before merging, so doc_count can be approximate (doc_count_error_upper_bound). Distribution makes global exactness expensive — the theme across 0002 and 0007.

Score yourself

Review artifacts — your revision kit

The compressed essence of every lesson lives in the cheat sheets and the glossary: query vs filter · BM25 · analysis · inverted index · segments · bool · aggregations · shard sizing. Print them; they're built to revise from.