LSM-Tree--BigTable 的理论模型

转载以下2篇文章

http://bofang.iteye.com/blog/1676698

http://www.cnblogs.com/raymondshiquan/archive/2011/06/04/2072630.html

LSM-tree主要目标是快速地建立索引。B-tree是建立索引的通用技术，但是，在大并发插入数据的情况下，B-tree需要大量的磁盘随机IO，很显然，大量的磁盘随机IO会严重影响索引建立的速度。特别地，对于那些索引数据大的情况（例如，两个列的联合索引），插入速度是对性能影响的重要指标，而读取相对来说就比较少。LSM-tree通过磁盘的顺序写，来达到最优的写性能，因为这会大大降低磁盘的寻道次数，一次磁盘IO可以写入多个索引块。

 

LSM-tree的主要思想是划分不同等级的树。以两级树为例，可以想象一份索引数据由两个树组成，一棵树存在于内存，一棵树存在于磁盘。内存中的树可以不一定是B-树，可以是其他的树，例如AVL树。因为数据大小是不同的，没必要牺牲CPU来达到最小的树高度。而存在于磁盘的树是一棵B-树。

 

 

数据首先会插入到内存中的树。当内存中的树中的数据超过一定阈值时，会进行合并操作。合并操作会从左至右遍历内存中的树的叶子节点与磁盘中的树的叶子节点进行合并，当被合并的数据量达到磁盘的存储页的大小时，会将合并后的数据持久化到磁盘，同时更新父亲节点对叶子节点的指针。

 

 

之前存在于磁盘的叶子节点被合并后，旧的数据并不会被删除，这些数据会拷贝一份和内存中的数据一起顺序写到磁盘。这会操作一些空间的浪费，但是，LSM-tree提供了一些机制来回收这些空间。

 

磁盘中的树的非叶子节点数据也被缓存在内存中。

 

数据查找会首先查找内存中树，如果没有查到结果，会转而查找磁盘中的树。

 

有一个很显然的问题是，如果数据量过于庞大，磁盘中的树相应地也会很大，导致的后果是合并的速度会变慢。一个解决方法是建立各个层次的树，低层次的树都比上一层次的树数据集大。假设内存中的树为c0, 磁盘中的树按照层次一次为c1, c2, c3, ... ck-1, ck。合并的顺序是(c0, c1), (c1, c2)...(ck-1, ck)。

 

为什么LSM-tree的插入很快

 

1. 首先，插入操作首先会作用于内存，并且，内存中的树不会很大，这会很快。

2. 合并操作会顺序写入一个或多个磁盘页，这比随机写快得多。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Google的BigTable架构在分布式结构化存储方面大名鼎鼎，其中的MergeDump模型在读写之间找到了一个较好的平衡点，很好的解决了web scale数据的读写问题。

MergeDump的理论基础是LSM-Tree (Log-Structured Merge-Tree), 原文见：LSM Tree

下面先说一下LSM-Tree的基本思想，再记录下读文章的几点感受。

LSM思想非常朴素，就是将对数据的更改hold在内存中，达到指定的threadhold后将该批更改批量写入到磁盘，在批量写入的过程中跟已经存在的数据做rolling merge。

拿update举个例子：

比如有1000万行数据，现在希望update table.a set addr='new addr' where pk = '833'，

如果使用B-Tree类似的结构操作，就需要：

1. 找到该条记录所在的page，

2. load page到内存（如果恰好该page已经在内存中，则省略该步）

3. 如果该page之前被修改过，则先flush page to disk

4. 修改数据

上面的动作平均来说有两次disk I/O，

如果采用LSM-Tree类似结构，则：

1. 将需要修改的数据直接写入内存

可见这里是没有disk I/O的。

当然，我们要说，这样的话读的时候就费劲了，需要merge disk上的数据和memory中的修改数据，这显然降低了读的性能。

确实如此，所以作者其中有个假设，就是写入远大于读取的时候，LSM是个很好的选择。我觉得更准确的描述应该是”优化了写，没有显著降低读“，因为大部分时候我们都是要求读最新的数据，而最新的数据很可能还在内存里面，即使不在内存里面，只要不是那些更新特别频繁的数据，其I/O次数也是有限的。

所以LSM-Tree比较适合的应用场景是：insert数据量大，读数据量和update数据量不高且读一般针对最新数据。

文章读下来有以下几点感受：

1. 基本思想早就有了，作者给出了较好的表现形式。

2. Merge是page/block级别的，而不是BigTable中的文件级别的。这一点主要原因可能是BigTable在分布式场景下做block级别很困那，而且GFS也不支持修改。

3. 其提出的比较标准比较有趣，将磁盘容量，转速等结合起来给出一个以美元为单位的cost标准，然后跟B-Tree结构的实现做了比较，结果当然是大大胜出。但是这里我觉得作者有些比较是不合理的，比如LSM使用log而B-Tree没有使用，这显然对B-Tree不公，其实B-Tree如果使用log，写入性能应该不比LSM差，顺序读取可能差一些。

4. 在Multi components 中，提出Ci/Ci+1的比例达到20的时候是最优的，这个数字意义不大，但是其中的分析方法对于Merge策略的选择是个启发。