研究Rocksdb已经有七个月的时间了，这期间阅读了它的大部分代码，对底层存储引擎进行了适配，同时也做了大量的测试。在正式研究之前由于对其在本地存储引擎这个江湖地位的膜拜，把它想象的很完美，深入摸索之后才发现现实很骨感，光鲜背后都有不为人知的辛酸苦辣。同时这也给幻想追求完美技术的我打了一针清醒剂，任何东西都是两面性的，没有好与坏，只有适合和不适合，世界就是这么残酷，多么痛的领悟！

Rocksdb也是一样，也有它的优势劣势及特定的适用场景。今天我就从设计的角度来分析一下。

基础架构

上图就是Rocksdb的基础架构。Rocksdb中引入了ColumnFamily(列族, CF)的概念，所谓列族也就是一系列kv组成的数据集。所有的读写操作都需要先指定列族。写操作先写WAL，再写memtable，memtable达到一定阈值后切换为Immutable Memtable，只能读不能写。后台Flush线程负责按照时间顺序将Immu Memtable刷盘，生成level0层的有序文件(SST)。后台合并线程负责将上层的SST合并生成下层的SST。Manifest负责记录系统某个时刻SST文件的视图，Current文件记录当前最新的Manifest文件名。  每个ColumnFamily有自己的Memtable， SST文件，所有ColumnFamily共享WAL、Current、Manifest文件。

架构分析

整个系统的设计思路很好理解，这种设计的优势很明显，主要有以下几点：

1.所有的刷盘操作都采用append方式，这种方式对磁盘和SSD是相当有诱惑力的；

2.写操作写完WAL和Memtable就立即返回，写效率非常高。

3.由于最终的数据是存储在离散的SST中，SST文件的大小可以根据kv的大小自由配置，            因此很适合做变长存储。

但是这种设计也带来了很多其他的问题：

1.为了支持批量和事务以及上电恢复操作，WAL是多个CF共享的，导致了WAL的单线程写        模式，不能充分发挥高速设备的性能优势(这是相对介质讲，相对B树等其他结构还是有优        势)；

2.读写操作都需要对Memtable进行互斥访问，在多线程并发写及读写混合的场景下容易形        成瓶颈。

3.由于Level0层的文件是按照时间顺序刷盘的，而不是根据key的范围做划分，所以导致各         个文件之间范围有重叠，再加上文件自上向下的合并，读的时候有可能需要查找level0层的          多个文件及其他层的文件，这也造成了很大的读放大。尤其是当纯随机写入后，读几乎是          要查询level0层的所有文件，导致了读操作的低效。

4.针对第三点问题，Rocksdb中依据level0层文件的个数来做前台写流控及后台合并触发，          以此来平衡读写的性能。这又导致了性能抖动及不能发挥高速介质性能的问题。

5.合并流程难以控制，容易造成性能抖动及写放大。尤其是写放大问题，在笔者的使用过程中实际测试的写放大经常达到二十倍左右。这是不可接受的，当前我们也没有找到合适的解决办法，只是暂时采用大value分离存储的方式来将写放大尽量控制在小数据。

适用场景

1.对写性能要求很高，同时有较大内存来缓存SST块以提供快速读的场景；

2.SSD等对写放大比较敏感以及磁盘等对随机写比较敏感的场景；

3.需要变长kv存储的场景；

4.小规模元数据的存取；

不适合场景

1.大value的场景，需要做kv分离；

2.大规模数据的存取