B-Trees and Their Variants

Lectures 7–9: AVL and Red-Black trees hold height to O(log₂n) by capping every node at 2 children. For n = 1,000,000 records that's a height of about 20 — brilliant, as long as the whole tree sits in RAM.

But databases, filesystems, and search indexes don't fit in RAM. They live on disk. And "one node visited" on a root-to-leaf path now means "one possible trip to the disk" — which changes the arithmetic completely.

A RAM access takes on the order of 100 nanoseconds. A disk seek takes 5–10 milliseconds — roughly 100,000× slower. A height-20 binary tree can mean 20 seeks per search: at 8ms each, that's 160ms for one lookup — brutal for a system answering thousands of queries a second.

And disks don't read "one key" at a time — they read in fixed-size blocks (typically 4–8 KB) no matter how little you asked for. So the right size for "one tree node" isn't one key; it's as many keys as fit in one block.

• Every node holds up to m − 1 sorted keys and up to m children.
• A node with k keys has exactly k + 1 children; child i holds every key strictly between key i−1 and key i — the same "between the keys" rule from ordinary BSTs, just generalized past 2 children.
• Every node except the root must have at least ⌈m/2⌉ children (at least ⌈m/2⌉ − 1 keys) — no node may be less than half full.
• Every leaf sits at exactly the same depth — the tree never gets lopsided.

• Order 5 ⟹ max 4 keys per node — the middle leaf [50 60 70 75] is exactly full.
• Min ⌈5/2⌉ = 3 children ⟹ min 2 keys — the right leaf [90 95] sits at the legal minimum; one key fewer and it would violate the half-full rule.
• Root [40 80] has 2 keys ⟹ exactly 3 children, and each child's keys fall strictly in its gap: <40, between 40 and 80, >80.
• All three leaves at the same depth — count it.

All worked examples in this lecture use m = 3, the smallest non-trivial order: max 2 keys / 3 children per node, min 1 key / 2 children (except the root). A small order keeps every split and merge fully visible within a few steps. Production database and filesystem B-trees use m in the hundreds or thousands, sized so one node = exactly one disk block.

The insertion and deletion rules are identical for every order. Master the order-3 traces that follow, and the same procedure applies unchanged at order 500 in production — only the arithmetic scales, not the idea.

At each node, scan its sorted keys to find which of the k + 1 gaps your target falls into, then descend into that child. Repeat until found — or until you're standing in a leaf with nowhere left to descend (a definitive "not present"). The animation traces both outcomes on an order-3 tree. The only genuinely new machinery in this lecture is keeping every node between half-full and full as you insert and delete — that's what the next two animations handle.

insert k into its correct leaf (descend by
    the SEARCH of L11·02a: at each node, scan
    the sorted keys, take the gap k falls in)

if that leaf now holds m keys (one too many):
    split it at the median:
        left half keeps the smaller keys
        right half keeps the larger keys
        median key moves UP into the parent
    // if the parent now overflows too, split IT
    // the same way — this can cascade to the root
    // if the root overflows, a NEW root is created
    // and the tree grows one level taller — upward

Order 3 means max 2 keys per node. A node briefly holding 3 keys is shown with a dashed red border — overflow, must split now. Amber boxes are leaves; teal boxes are internal (routing) nodes. Watch the median: it always escapes upward, never sideways.

• No underflow: the leaf still has ≥ 1 key after removal — done.
• Merge: leaf empties, sibling is also at the minimum — merge them, pulling the parent's separator key down between them.
• Borrow through the parent: leaf empties, but a sibling has a spare key — rotate one key down from the parent and one up from the sibling.
• Delete an internal key → successor swap, then repair: a key can only be physically removed at a leaf, so replace it with its inorder successor (always in a leaf), then fix that leaf's underflow — the repair can cascade upward and shrink the tree by a whole level.

This is the exact same tree you just built. Deleting 10 → 9 → 5 → 4 in sequence walks you through all four cases without ever introducing a new example — by the last step you'll have personally traced why deleting one internal key can ripple all the way to the root. Every removal is shown as its own step before the repair: a dashed red node marks underflow — a node below its key minimum (· = empty) that the next step must fix.

In a B-tree, real data can sit at any node — root, internal, or leaf. So answering "give me every record between 20 and 80" means jumping in and out of internal nodes with no shortcut between neighboring leaves. Yet this exact kind of query is everywhere: SELECT … WHERE age BETWEEN 20 AND 80, listing a directory alphabetically, streaming a large file's blocks in order.

Force all real data into the leaves only. Internal nodes hold nothing but routing copies of keys — pure signposts, never touched by a range scan. Then thread every leaf to its right neighbor with a pointer. Once you've found where a range starts, you just walk the linked leaves left to right. This is exactly how MySQL InnoDB, PostgreSQL, and the NTFS/ext4 directory indexes work — B+ trees, not plain B-trees.

Store only copies of keys, purely to steer a search left or right. Hold no data of their own. Obey the same max-m-children rule as a B-tree.

Store the real keys (and, in a database, the record or a pointer to it) — plus one extra pointer to the next leaf, threading every leaf into one sorted linked list.

A leaf split never removes a key — it copies the smallest key of the new right leaf up as the separator (the data must stay in a leaf). How many keys land on each side follows one rule at every order: when a leaf overflows to m keys, the left leaf keeps ⌈m/2⌉ of them and the right leaf keeps ⌊m/2⌋. Order-3's overflow of 3 keys splits 2-left/1-right, so the copied-up key — the smallest of the right leaf — happens to also be the largest of the three, as the animation below shows. That's a coincidence of the 1-key right half, not the rule: at order 4 (4 keys → 2-and-2) or order 5 (5 keys → 3-and-2), the copied-up key is just the first key of whichever keys landed in the right half, no longer the largest overall. An internal split moves its true median up, exactly like a B-tree (there's no data attached to a signpost, so nothing needs to stay behind).

Below every tree snapshot you'll see the leaf-to-leaf linked list spelled out. However tangled the tree above gets, that chain always stays a single, unbroken, sorted sequence — the whole point of a B+ tree.

Deleting a key that was never copied into an internal node is exactly as simple as a leaf-only delete gets. Deleting one that borrows across a boundary is different: after the borrow, the internal signpost above it is now stale and must be rewritten to the new smallest key of the leaf it points to. When neither sibling has a key to spare, borrowing isn't an option — the leaves merge instead, and the parent's separator is simply discarded (it was only ever a copy, so nothing needs to move down). If that empties the parent's own key count, the underflow cascades one level up — and there the separator does get pulled down, exactly like a plain B-tree merge, because an internal node carries no data of its own to protect.

Every insert or delete near a leaf boundary in a real database index pays this small bookkeeping cost. It's the price of keeping the leaf chain always walkable in order — cheap per operation, and the reason range queries stay fast forever.

A split only guarantees a node stays at least half full (⌈m/2⌉ − 1 keys minimum). After years of real-world churn, most nodes in a live B-tree or B+ tree settle near that 50% floor — meaning roughly half of every disk block read is empty space. At the scale of a production index, that's an enormous amount of wasted I/O and cache.

Delay splitting for as long as possible. Before splitting a full node, first check whether a sibling has spare room and shift keys sideways through the parent — an insertion-time version of the borrow-from-sibling trick you already used in deletion. Only split when both a node and its sibling are completely full — and even then, split two full nodes into three roughly-two-thirds-full ones, instead of one full node into two half-full ones.

• The root has between 2 and 2⌊(2m−2)/3⌋+1 children.
• Every other internal node has between ⌈(2m−1)/3⌉ and m children — roughly two-thirds full to completely full, not one-half to full.
• Every leaf sits at the same depth — identical to a B-tree.

Insertion and — especially — deletion logic must now respect a two-thirds floor instead of a one-half floor, which makes both noticeably more intricate to implement correctly. That extra complexity is exactly why B* trees, despite better space usage, are far rarer in production than B and B+ trees. The most famous real user: the classic Apple HFS filesystem's catalog file.

• Underflow, sibling has spare keys: borrow through the parent, exactly like a B-tree — no node count change.
• Underflow, sibling is also at the minimum: a plain B-tree would just merge the two into one. A B* tree can't — two-thirds-full plus two-thirds-full is more than one node's capacity (for order 4: 2+2 keys don't fit in a max-3 node).
• So B* deletion pulls in a second sibling too — three nodes at/near the minimum — and redistributes all of them across only two nodes: the exact mirror of the two-to-three split, run backwards.

Same order-4 tree the insertion animation just built, continued: [1,2] · 3 · [4,5] · 7 · [8,9]. First a quick insert to set up an honest "sibling has spare keys" case, then two deletions — one that borrows cleanly, and one that forces the three-into-two collapse.