LSM存储引擎

LSM(log structured merge Trees)是一种存储引擎，存储引擎有两个最基本的操作就是读和写。LSM之所以出现的根本原因就在于磁盘的顺序读写性能远远高于随机读写。

问题

对于存储引擎来说，如果只是写而不考虑读的话就完全不需要有那么多花里胡哨的设计，只需要保证写基本是顺序写就可以。最简单的实现就是在内存中加个缓冲区，当缓冲区中的数据满时，刷新到磁盘上。但是要保证数据的快速读取，就必须要知道每一条数据具体存储在文件的什么位置，或者大概位置。在没有索引的情况下，只能对整个文件进行遍历和匹配，这种速度显然是无法接受的。为了提高读取速度，出现了索引。

索引的核心功能就是快速定位数据，而索引的结构又跟数据的存储方式密切相关。最简单的索引，我们将所有的数据都存储在一个文件中，可以使用索引存储每一行数据的key值在文件中的偏移量，即：(key, offset)，有这样一个列表之后，我们可以通过哈希在查找是快速找出每一行数据对应的索引记录，进而定位到数据的位置。

但是当数据量增加的时候索引的大小也会随之增大，当索引已经大到无法在内存中保存了，就只能将其存储在硬盘中了。

这时候如果索引还像一开始那样存储，索引需要分很多次加载到内存中，由于索引是杂乱无章的，很有可能一些加载完全得不到有用的信息。

于是在传统的关系型数据库中普遍采用了B+树作为索引，一个很重要的原因在与它可以分段加载的内存中同时每一次加载都能获取有用的信息。但是根本上来说B+树索引只是一开始普通索引的结构的改变，其本质上还是一个索引记录对应一条实际数据，(这点从B+树索引的叶子结点结构就能明显看出来)。那么对于这样一个结构来说，维护这棵树的成本是很高的，新增、