anchor.diff:  
   Thus we dramatically improve the performance of insertions without hurting the IO cost of queries.
   
  -### Functional Persistence
  +==== Functional Persistence
   
   Now that we get the sketch of how to combine event logs and B+ trees, let's see the beauty of making the whole thing functional and persistent!
   Since the combined B+/log data structure primarily only modifies nodes near the root, we can take advantage of the reduced modification to achieve reduced IO when persisting the tree.
  
positive.code: # Hitchhiker tree
  
  This document will attempt to sketch out the big ideas in the hitchhiker tree.
  It will also attempt to call out various locations in the implementation where features are built.
  
  ## High-level understanding
  
  The goal of the hitchhiker tree is to wed three things: the query performance of a B-tree, the write performance of an append-only log, and convenience of a functional, persistent datastructure.
  Let's look at each of these in turn, before looking at how we'll unify them.
  
  ### B+ trees win at queries
  
  You might remember an important theorem from data structures: the theoretically best-performing data structure for looking up sorted keys cannot be faster than `O(log(n))` ++O(log(n))++ +O(log(n))+.
  Since sorted trees provide a solution for this, we'll start with them.
  Now, a common sorted tree for this purpose is the Red-Black tree, whose actual query performance is `2*log`~`2`~`(n)` (the write performance is log\_2(n)).
  The factor of 2 comes from the partial imbalances (which are still amsymtotically balanced) that the algorithm allows, and the base 2 of the log comes from the fact that it's a binary search tree.
  
  A less popular sorted tree is the AVL tree--this tree achieves log\_2(n) query performance, at the cost of 2\*log\_2(n) for inserts.
  We can already see a pattern--although many trees reach the asymptotic bound, they differ significantly in their constant factors.
  
  The tree that the hitchhiker tree is based off of is the B+ tree, which achieve log\_b(n) query performance.
  Since `b` can be very large (on the order of 100s or 1000s), these trees are excellent for slower data medium.
  This is because each node can contain huge numbers of keys, meaning that by only keeping a tiny number of index nodes in memory, we can rapidly identify the location of the desired data on the slower medium.
  
  
negative.code: Their internal nodes only contain enough data to maintain the sort on the data structure.
  We'll come back to why we like B+ trees later on.
  
  ==== Event logs win at writing data
  
  Do you know the fastest way to write data?
  Append it to the end of the file.
  There's no pointers, no updating of data structures, no extra IO costs incurred.
  
  Unfortunately, to perform a query on an event log, we need to replay all the data to build a temporary data structure, which we can then query.
  That replay costs `O(n)`, since it touches every event written.
  
  ==== Unifying B+ trees and event logs
  
  The first idea to understand is same as the core idea in the fractal tree: how can we combine the write performance of an event log with the query performance of a B+ tree?
  The answer is that we're going to "overlay" an event log on the B+ tree!
  