数据库持久化比较

reids 的 RDB 和 AOF 

      RDB，以某个时间点为切面，将这个时候内存中的数据写入到磁盘。

      AOF ，将全部内存中的改动记录在AOF日志里，要恢复的时候，依次按操做恢复。当AOF过大时，还会进行重写，把重复的操做合并。

 

mongodb(相似于redis aof) 
mongodb与MySQL不一样，mysql的每一次更新操做都会直接写入硬盘，可是mongo不会，作为内存型数据库，数据操做会先写入内存，而后再会持久化到硬盘中去。
mongodb在启动时，专门初始化一个线程不断循环，用于在必定时间周期内来从defer队列中获取要持久化的数据并写入到磁盘的journal(日志)和mongofile(数据)处。

 

hbase
hbase采用的LSM思想(Log-Structured Merge-Tree)。

 B+树

根节点和枝节点很简单，分别记录每一个叶子节点的最小值，并用一个指针指向叶子节点。

叶子节点里每一个键值都指向真正的数据块（如Oracle里的RowID），每一个叶子节点都有前指针和后指针，这是为了作范围查询时，叶子节点间能够直接跳转，从而避免再去回溯至枝和跟节点。

B+树最大的性能问题是会产生大量的随机IO，随着新数据的插入，叶子节点会慢慢分裂，逻辑上连续的叶子节点在物理上每每不连续，甚至分离的很远，但作范围查询时，会产生大量读随机IO。

对于大量的随机写也同样，举一个插入key跨度很大的例子，如7->1000->3->2000 ... 新插入的数据存储在磁盘上相隔很远，会产生大量的随机写IO.

从上面能够看出，低下的磁盘寻道速度严重影响性能（近些年来，磁盘寻道速度的发展几乎处于停滞的状态）。

2 LSM树

为了克服B+树的弱点，HBase引入了LSM树的概念，即Log-Structured Merge-Trees。

为了更好的说明LSM树的原理，下面举个比较极端的例子：

如今假设有1000个节点的随机key，对于磁盘来讲，确定是把这1000个节点顺序写入磁盘最快，可是这样一来，读就悲剧了，由于key在磁盘中彻底无序，每次读取都要全扫描；

那么，为了让读性能尽可能高，数据在磁盘中必须得有序，这就是B+树的原理，可是写就悲剧了，由于会产生大量的随机IO，磁盘寻道速度跟不上。

LSM树本质上就是在读写之间取得平衡，和B+树相比，它牺牲了部分读性能，用来大幅提升写性能。

它的原理是把一颗大树拆分红N棵小树， 它首先写入到内存中（内存没有寻道速度的问题，随机写的性能获得大幅提高），在内存中构建一颗有序小树，随着小树愈来愈大，内存的小树会flush到磁盘上。当读时，因为不知道数据在哪棵小树上，所以必须遍历全部的小树，但在每颗小树内部数据是有序的。因此LSM树读是比较慢的。

以上就是LSM树最本质的原理，有了原理，再看具体的技术就很简单了。

1）首先说说为何要有WAL（Write Ahead Log），很简单，由于数据是先写到内存中，若是断电，内存中的数据会丢失，所以为了保护内存中的数据，须要在磁盘上先记录logfile，当内存中的数据flush到磁盘上时，就能够抛弃相应的Logfile。

2）什么是memstore, storefile？很简单，上面说过，LSM树就是一堆小树，在内存中的小树即memstore，每次flush，内存中的memstore变成磁盘上一个新的storefile。

3）为何会有compact？很简单，随着小树愈来愈多，读的性能会愈来愈差，所以须要在适当的时候，对磁盘中的小树进行merge，多棵小树变成一颗大树。提升读的性能。