Log-structured merge-tree

In computer science, the log-structured merge-tree (or LSM tree) is a data structure with performance characteristics that make it attractive for providing indexed access to files with high insert volume, such as transactional log data. LSM trees, like other search trees, maintain key-value pairs. LSM trees maintain data in two or more separate structures, each of which is optimized for its respective underlying storage medium; data is synchronized between the two structures efficiently, in batches.

Log-structured merge-tree
TypeHybrid (two tree-like components)
Invented1996
Invented byPatrick O'Neil, Edward Cheng, Dieter Gawlick, Elizabeth O'Neil
Time complexity in big O notation
Algorithm Average Worst case
Insert O(1) O(1)
Find-min O(N) O(N)
Delete-min O(N) O(N)

One simple version of the LSM tree is a two-level LSM tree.[1] As described by Patrick O'Neil, a two-level LSM tree comprises two tree-like structures, called C0 and C1. C0 is smaller and entirely resident in memory, whereas C1 is resident on disk. New records are inserted into the memory-resident C0 component. If the insertion causes the C0 component to exceed a certain size threshold, a contiguous segment of entries is removed from C0 and merged into C1 on disk. The performance characteristics of LSM trees stem from the fact that each component is tuned to the characteristics of its underlying storage medium, and that data is efficiently migrated across media in rolling batches, using an algorithm reminiscent of merge sort.

Diagram illustrating compaction of data in a log-structured merge tree

Most LSM trees used in practice employ multiple levels. Level 0 is kept in main memory, and might be represented using a tree. The on-disk data is organized into sorted runs of data. Each run contains data sorted by the index key. A run can be represented on disk as a single file, or alternatively as a collection of files with non-overlapping key ranges. To perform a query on a particular key to get its associated value, one must search in the Level 0 tree and each run.

A particular key may appear in several runs, and what that means for a query depends on the application. Some applications simply want the newest key-value pair with a given key. Some applications must combine the values in some way to get the proper aggregate value to return. For example, in Apache Cassandra, each value represents a row in a database, and different versions of the row may have different sets of columns.[2]

In order to keep down the cost of queries, the system must avoid a situation where there are too many runs.

Extensions to the 'leveled' method to incorporate B+ tree structures have been suggested, for example bLSM[3] and Diff-Index.[4]

LSM trees are used in data stores such as Bigtable, HBase, LevelDB, SQLite4,[5] Tarantool,[6] RocksDB, WiredTiger,[7] Apache Cassandra, InfluxDB[8] and ScyllaDB.

References
  1. O'Neil 1996, p. 4
  2. "Leveled Compaction in Apache Cassandra : DataStax". February 13, 2014. Archived from the original on February 13, 2014.
  3. http://www.eecs.harvard.edu/~margo/cs165/papers/gp-lsm.pdf
  4. http://researcher.ibm.com/researcher/files/us-wtan/DiffIndex-EDBT14-CR.pdf
  5. "SQLite4 with LSM Wiki". SQLite.
  6. "An application server together with a database manager". Retrieved April 3, 2018. Tarantool’s disk-based storage engine is a fusion of ideas from modern filesystems, log-structured merge trees and classical B-trees.
  7. "GitHub - wiredtiger/wiredtiger: WiredTiger's source tree". December 4, 2019 – via GitHub.
  8. Dix, Paul (October 7, 2015). "[New] InfluxDB Storage Engine | Time Structured Merge Tree".
General
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.