In this chapter
We'll meet LSM trees — a real, general storage-engine pattern (memtable, sequential SSTables, background compaction) that accepts writes as fast as physically possible and defers organizational work to later — the real, physical reason GreenMart's Cassandra cluster barely noticed the same write load that struggled its B-tree-based relational database.
The Problem in Real Life
Sarah pulls up Cassandra's own write path — familiar from before, but now with a real, physical question attached. "We covered this as 'how Cassandra writes,'" she says. "I want to show you the real, general shape underneath it — the same real idea other write-heavy systems use too, not just Cassandra specifically."
Mike nods. "So this isn't a Cassandra thing. It's a real pattern."
Is this specific to Cassandra, or a real, general pattern other systems use too?
Mike
Organize First, Then Write vs. Write First, Organize Later
Writes land sequentially — memory first
A memtable plus a sequential log write makes LSM writes dramatically faster than a B-tree's random-access node rewrites.
Compaction — the real, deferred cost
A background process merges SSTables over time, paying the organizational cost LSM trees deliberately defer at write time.
LSM Trees: Writes First
An LSM tree (log-structured merge-tree) is a real, general storage-engine pattern that takes the opposite real bet from a B-tree: instead of keeping data thoroughly organized on disk at all times, it accepts new writes as fast as physically possible, and defers real organizational work until later, in the background.
- The memtable — writes land in memory first. A new write doesn't touch disk immediately at all — it lands in a real, in-memory structure called a memtable, plus a real, sequential write to an on-disk log (for real crash safety, the same durability instinct behind Act 3's own journaling chapter). Because the memtable is in memory and the log write is purely sequential — appending to the end of a file, not seeking to a scattered real location the way a B-tree's node rewrite does — this is genuinely, dramatically faster than GreenMart's own B-tree's real random-access write pattern.
- SSTables — the memtable flushed to disk, in order. Once the memtable fills up, its real contents get written out to disk as one new, immutable file — a Sorted String Table (SSTable) — written once, sequentially, and never modified again. Over real time, many SSTables accumulate, each one a real, ordered snapshot of writes from a given window.
- The real cost this defers: reads. A single real key might now exist in the memtable and across several real SSTables, since a later write could have updated it after an earlier SSTable was already flushed. A read may genuinely need to check the memtable and multiple SSTables, newest first, until it finds the real answer — a real, direct cost LSM trees accept at read time, in exchange for the fast write path.
- Compaction — the real, background clean-up. A background real process called compaction periodically merges multiple SSTables into fewer, larger ones, discarding real outdated or overwritten entries along the way — real, ongoing work that keeps read costs from growing unbounded over time, at the real, honest price of real background CPU and disk I/O the system pays continuously, not at the moment of any single write.
| Operation | B-Tree (Act 6, ch2) | LSM Tree |
|---|---|---|
| Write pattern | Random access — find and rewrite a specific node | Sequential append — memtable + log, no seeking |
| Immediate write cost | Can cascade (node split) | Low and predictable |
| Read pattern | One direct path down the tree | May check memtable + multiple SSTables |
| Background cost | None significant | Compaction — ongoing, real CPU/I/O in the background |
GreenMart now has the real, physical reason Cassandra's own write path barely noticed the new event-logging load: sequential, memory-first writes, with the real organizational cost deliberately deferred to a background compaction process instead of paid immediately, the way a B-tree's own node rewrite demands.
Key Takeaway
An LSM tree accepts writes fast — sequentially, memory-first — and defers organizational work to a background compaction process, trading a real, deferred read/compaction cost for dramatically better real write throughput, the exact opposite bet a B-tree makes.
Why This Matters
Recognizing the real, general LSM pattern — not just "how Cassandra happens to work" — lets GreenMart correctly predict how any future write-heavy real system will actually behave, and understand the real, honest cost (background compaction, potentially slower individual reads) that fast writes are never actually free from.
GreenMart now has both real storage-engine families — B-trees (read-optimized) and LSM trees (write-optimized) — and the real, physical reason each behaves the way it does. The next chapter puts them directly side by side, closing the real comparison this whole Act has been building toward.