Log structured merge trees

[at15]

Originally from https://github.com/at15/papers-i-read/issues/21

I think I will first write notes it gitbook and then summarize them with better format into the tex

• blog: sstable and leveldb https://www.igvita.com/2012/02/06/sstable-and-log-structured-storage-leveldb/
• gist: https://gist.github.com/sreeix/45aec4f51a3578a20700
• quora: https://www.quora.com/How-does-the-Log-Structured-Merge-Tree-work
• the morning paper
  • https://blog.acolyer.org/2014/11/26/the-log-structured-merge-tree-lsm-tree/ not very useful
  • https://blog.acolyer.org/2015/04/30/scaling-concurrent-log-structured-data-stores/
• papers-we-love: https://www.meetup.com/Papers-we-love-Bangalore/events/225418614/
• paper: bigtable
• paper: cassandra
• paper: O'Neil 96 LSM Trees
• paper: bLSM:∗ A General Purpose Log Structured Merge Tree
• paper: cLSM: Scaling Concurrent Log-Structured Data Stores
• paper: AsterixDB: A Scalable, Open Source BDMS LSM B-Tree http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf
• the detail of merge
  • wired tiger http://source.wiredtiger.com/2.3.1/lsm.html didn't mention much about it
• B+ tree leafs are linked together like sstable? from @czheo

DB

• SQLite http://www.sqlite.org/src4/doc/trunk/www/lsmusr.wiki

Extra

• boltdb have some comparison with rocks and levledb https://github.com/boltdb/bolt#leveldb-rocksdb, it used to be one of the engine for influxdb
• redis and lsm (how redis implemented its log .... or durability, and how it implemented its complex structures, set, etc.)
• influxdb guys done some benchmark before https://www.influxdata.com/benchmarking-leveldb-vs-rocksdb-vs-hyperleveldb-vs-lmdb-performance-for-influxdb/

[at15]

Blog

• memtable + ss index + sstable
  • are keys sorted in memtable
  • the memtable is a hashtable or other? like I can use two array, one for key, one for value, it's just need to loop to find the array index of a given key
  • does sstable store key when using ss index
  • how is collapse achieved

leveldb code

• https://github.com/google/leveldb/blob/master/db/memtable.cc

Take away

• sstable indexes (key + offset) are loaded into memory
• write goes to memtable
• memtable get flushed to disk
• sstable are merged (collapsed together?)

[at15]

Quora

Take away

• how to manage efficiently merging only sub-portions of the key-space
  • LevelDB/RocksDB tackles it by liberally relying on a b-tree based intermediate layer, the filesystem.
  • The LSM in Cassandra, HBase, and Hypertable are very close to the LevelDB "filesystem layered" approach

C_0, C_1 (this is not the case for sstable guys I guess)

• C_0 is AVL tree
• C_1 is B tree

About merging process

Once written, older generations are never modified. You do row modifications by rewriting the rows/records into a newer generation where it is found first.

The nice thing is that the old data is still being used by the system while this mergy happens "in the background". During the merge process, rows/records modified by newer generations or marked deleted are removed by simply not writing them. Once the merge is complete, this combined generation replaces the two it merged.

[at15]

Original paper

• C_1 (on disk) level is SB-Tree

The most important part in the original paper should be about rolling merge, and especially how it handles recovery, but as I assume, its main focus is on index

• TODO: is the original paper focus on index but later application use this method for storing actual data

[at15]

Some questions asked by other students

• what happens when I delete something in the lower level, if you delete something that is in memory, you can add a tombstone for it, but if it is in disk, do you load it to buffer and add a tombstone for it, or you read from multi levels and apply the filter when merge