B-Trees: Data on Disk

In this chapter

We'll go deep on B-trees from a genuinely new, physical storage-engine angle — nodes deliberately sized to match real disk blocks, making reads fast (few, large disk operations) but writes genuinely expensive (a full node rewrite, or a cascading split) — the real, physical reason GreenMart's own relational database struggled under heavy write load.

8–10 min

The Problem in Real Life

Sarah pulls up the relational database's own index structure — the same real B-tree already met, once before, as a way to speed up queries. "We looked at this before," she says, "but only from the query side. I want to show you why it's actually shaped this way, physically, on disk."

Mike remembers the earlier lesson. "Fast lookups, right? What's left to explain?"

We already covered B-trees for fast lookups. What's different about looking at them now?

Mike

A B-Tree as an Index vs. A B-Tree as Physical Disk Layout

Nodes sized to match real disk blocks

A B-tree node is deliberately sized so one disk read fetches one whole, key-packed node — minimizing real I/O operations.

Writes can cascade — the real cost of a split

Inserting into a full node forces a split, cascading real disk writes to multiple nodes and their parent.

A B-tree, seen from the physical storage-engine layer, isn't just "a structure that makes lookups fast" — it's a real, deliberate shape, sized and organized specifically around how disks actually read and write data (Act 1's own IOPS vocabulary), and that physical shape is exactly what makes writes genuinely more expensive than reads.

Nodes sized to match real disk blocks. A B-tree's real nodes — sometimes called pages — are deliberately sized to align with the real block size a disk actually reads and writes in one physical operation (Act 1, Act 3's own vocabulary). This isn't an implementation detail; it's the entire real point: one disk read fetches one whole real node, packed with many real keys, instead of wasting a real I/O operation fetching just one.
Why this makes reads genuinely fast. Because each real node holds many keys, and the tree stays genuinely shallow (a real B-tree with a high branching factor might need only 3-4 real levels to hold millions of records), finding any specific real record takes only a handful of real disk reads — a direct, physical payoff of Act 1's own IOPS lesson: minimizing the number of real, separate disk operations a lookup requires.
Why this makes writes genuinely more expensive. Inserting a new real key means finding the correct real node (a real read) and then writing that entire node back to disk (a real write) — even though only one small key actually changed, the whole real block gets rewritten. Worse: if a node is already full, it must split into two, which means writing multiple real nodes and updating the real parent node that points at them — a real, cascading write cost proportional to how full the tree already is.
Why this is genuinely, deliberately not the same lesson as B-trees' own earlier introduction. That earlier lesson covered B-trees from the query side — why an index speeds up a WHERE clause. This chapter's own real, physical angle explains why the write side of GreenMart's own relational database genuinely struggles under heavy load: every single write to a B-tree-based table risks a real, cascading, disk-block-level cost that has nothing to do with the query language at all.

GreenMart now has the real, physical reason its own relational database's write performance genuinely degrades under heavy load: B-trees are deliberately shaped for fast, few-block reads, and that same real shape makes every write a potentially expensive, cascading, block-rewriting operation.

Key Takeaway

A B-tree's real nodes are sized to match a disk's own block size, which is exactly what makes reads fast (few, large disk operations) and writes genuinely expensive (a full node rewrite, or a cascading split, for even one small change) — a real, physical trade-off, not a query-language limitation.

Why This Matters

GreenMart's own relational database's real write struggles under the new event-logging workload aren't a configuration mistake — they're the direct, physical, expected consequence of a B-tree's own deliberate design, choosing fast reads at a real, structural cost to writes.

GreenMart now has the real, physical reason B-trees favor reads over writes. The next chapter meets the real alternative Cassandra's own storage engine is actually built on: LSM trees, which flip this trade-off deliberately in the other direction.