Rocksdb的优劣及应用场景分析

研究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的大小自由配置，