2

I'm developing on a NoSQL database that uses 64-bit hash-based B+ trees for some of its indexes, now I'm looking into applying Snapshot Isolation Multiversion concurrency control (SI MVCC) on the persistent B+ tree.

The first issue I'm confronted with is that every node in the B+ tree holds a pointer to the next node in the tree; a 64-bit pointer to a byte address inside the file where the next node is located. Therefore, when I update a record node all the nodes in that branch of the B+ tree all the way to the root node has to be updated - is there a better/simpler way of doing this to avoid so many disk updates (typically 4 'disk sectors'/nodes has to be updated at every record write, each node is fit inside a single disk sector)? A seperate directory record that holds an overview of all the linked nodes perhaps?

  • for leaves, I suppose that you could store the revisions in the leaf itself. A revision would be the real leaf with pointers to next and previous leaves. If one of these get updated, the update will take the form of a new revision with its own pointers. For inner nodes, maybe a similar strategy can be followed. – didierc Jan 05 '13 at 16:24
  • 2
    there's a paper for a similar technology called "stratified b-tree", maybe you heard of it? – didierc Jan 05 '13 at 16:51
  • @didierc I will have a look at that, thanks. –  Jan 05 '13 at 19:25

0 Answers0