Log-Structured Merge Tree (LSM Tree)

一种树，适合于写多读少的场景（主要是大数据No SQL数据库，例如HBase、Cassandra、SQLite、Mongodb等）。主要是利用了延迟更新、批量写、顺序写磁盘（磁盘sequence access比random access快）。

背景

回顾数据存储的两个“极端”发展方向

加快读：加索引（B+树、二分查找树等）。适合读多写少的场景。

目的是为了尽快查到目标数据，从而提高查询速度；但由于写入数据时同时要维护索引且涉及节点分裂与合并，故写效率较低。

加快写：纯日志型，不加索引，数据以append方式追加写入。适合写多读少的场景。

append利用了“磁盘顺序写比任意写性能高”的特性，使得写入速度非常高（接近磁盘理论写入速度）；因缺乏索引支持故需要扫描所有记录故查询性能低（好一些的进一步支持单数据查询或范围查询，例如HBase）。在大数据工具方面应用广泛，典型的是Kafka数据存储、MySQL和HBase等数据库中的WAL技术。

if we are interested in write throughput, what is the best method to use? A good starting point is to simply append data to a file. This approach, often termed logging, journaling or a heap file, is fully sequential so provides very fast write performance equivalent to theoretical disk speeds (typically 200-300MB/s per drive).

Benefiting from both simplicity and performance log/journal based approaches have rightfully become popular in many big data tools. Yet they have an obvious downside. Reading arbitrary data from a log will be far more time consuming than writing to it, involving a reverse chronological scan, until the required key is found. This means logs are only really applicable to simple workloads, where data is either accessed in its entirety, as in the write-ahead log of most databases, or by a known offset, as in simple messaging products like Kafka.

 

LSM Tree（Log Structure Merge Tree）

LSM Tree以第二种为基础再结合了第一种，其目标在于在尽可能保证高写入性能的同时提高查询性能。

LSM trees sit in the middle-ground between a journal/log file and a traditional single-fixed-index such as a B+ tree or Hash index. 

　　In essence they do everything they can to make disk access sequential.

写采用【先写内存+日志 攒一定量再 批量顺序append磁盘】故写性能非常高，而为提高查效率所做的改进：数据存储上按key排序组织使得可二分查找（单数据查询）或范围查询，且不用移动数据。

但客户端发来的数据并不会按key有序故若数据存储上按key排则持久化时可能需要移动数据从而影响写入性能，怎么办？，但进一步做了【在内存对数据按key排序、数据批量append到文件、多层次文件组织、延迟更新】等处理。

 

原理

 

针对KV型数据的存储。

主要概念：MemTable、Immutable MemTable、SSTable、manifest

原理：简而言之，就是先在内存对数据排序，然后批量分批将数据以append方式写入磁盘文件，这样文件数据就是按key有序的，从而可通过二分查找及文件key的范围来提高查询速度。

1、数据读写时均需指定key。

2、add数据时先写入内存Buffer（称为Memtable）。

这里面的数据按key排序（可通过跳表或各种树实现）；

数据写入Memtable前会以WAL（write-ahead-log）方式先写log到disk，以使Memtable中数据在机器故障后可根据log恢复。更好的方式是Memtable满后变成Immutable Memtable并生成一个新的Buffer接收写入，每个接收写入的Memtable对应一个WAL文件。

3、当Memtable里数据达到一定量（个数、大小等）后数据被批量地、以append方式顺序写入disk成为一个文件，可见此时文件内部是按key有序的了（称为为Sorted String Table，即SSTable）。

4、所有写入Memtable或disk的数据均不会被修改：新的add、delete、update操作在内部实现上都是产生新的entry，而不会去修改同key的entry，因此存在冗余：同一个key有多个版本的数据、不同文件间有相同key的entry。

5、解决冗余：系统内部会周期性对disk上若干文件进行合并，合并时会remove any duplicated updates or deletions（是以谓之“延迟更新”）。由于各文件内部是有序的故合并非常快。

Level Based Compaction：Level DB中逻辑上以level对文件分类（如上图），下层level的文件由上层level的文件合并而成；level0中不同文件中可能有相同key，但level1及以下level不再会有冗余。

6、read操作：先从Memtable中查，若未查到则对各disk文件按文件创建时间由新到旧对各文件遍历查。

由于文件内部是按key有序的，故相比于纯日志型存储，LSM Tree查询更快（如可用二分查找）；

由于需要遍历各文件故查询速度相比于B+树差，且文件越多查的性能越慢；

为提高查询效率，措施：增加合并操作频率以减少文件数量、生成大的排序的文件；对每个文件使用布隆过滤器以可快速确定此文件是否有指定key的entry；Level Based Compaction使得可以记录每个level中key的范围（mainfest文件）从而查询时每个level只要查一个文件。

 

总结

特点：

写入的数据借助WAL技术写内存和日志后就返回，且在内存按key排序了；

disk写是批量、顺序写；

写入的数据不可变，不会被修改。add、delete、update在内部都是add操作，存在冗余，由定期的合并操作来消除冗余；

因数据在内存排过序，故在写入disk后每个文件内部也按key有序；

文件内部按key有序，故合并操作很快（线性复杂度）；有利于查询（二分查找等）

高写入性能的原因：WAL写，写内存和日志后就返回；写入disk是批量、顺序追加写；数据只增不减，故不用进行加锁等同步操作，并发访问能力强

与加B+树等树型索引结构的存储方式比：写性能大幅度提高，读性能差些。

与纯日志型比：多了合并操作（虽是额外开销但因文件是各自内部有序的故合并很快）、查询性能提高

 

典型应用：Level DB，写性能远大于读性能；缺点之一是还不支持分布式。

此外，HBase、Cassandra、SQLite、Mongodb等亦是基于LSM tree；时序数据库通常有大量的采用数据写入，故LSM tree在时序数据库中也很常用（HBase也算一种时序数据库）。

关于时序数据库的基本概念，可参阅这篇文章的简洁介绍，主要有 metric、point、timestamp、tag、field。

 

参考资料

http://www.benstopford.com/2015/02/14/log-structured-merge-trees/（主）

https://www.cnblogs.com/vajoy/p/5471308.html