Rocksdb的优劣及应用场景分析

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

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

基础架构

Rocksdb的优劣及应用场景分析_第1张图片

       上图就是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.大规模数据的存取

你可能感兴趣的:(Rocksdb的优劣及应用场景分析)