Reference · Cheat sheet

Segments & merges

The compressed essence. Print it, pin it.

From lesson 0005See also glossary

The model in one line

buffer —refresh→ small segments —merge→ big segments

Segment = a self-contained inverted index (lesson 0004), immutable once written.
Shard = a Lucene index = a collection of segments + a commit point.
A search runs against every segment in the shard, then combines — so segment count is a cost.

Lifecycle

Event	What happens
index a doc	enters in-memory buffer — not searchable yet
refresh (~1s)	buffer → new segment in filesystem cache → now searchable (“near real-time”)
delete	doc marked in `.del`; stays on disk, filtered from results
update	= delete-mark old + index new version in a new segment
merge (background)	combine small→big; deleted/old docs not copied → disk reclaimed; throttled to protect search
flush / commit	fsync segments to disk + write commit point (durability)

Reflexes

“New doc not visible” → refresh interval, not a bug.
“Deleted docs but disk didn't shrink” → space frees only at merge.
Bulk indexing slow → raise/disable refresh_interval → fewer segments, less merge load.
Search slow, many tiny segments → too-frequent refresh / lots of small writes.
force merge only on read-only indices; never on an actively-written one.

Inspect it

GET /_cat/segments/<index>?v&h=segment,docs.count,docs.deleted,size
POST /<index>/_refresh                          // force buffer → segment now
POST /<index>/_forcemerge?max_num_segments=1     // read-only indices only!

← lesson 0005 · Source: Definitive Guide — Segment merging