湖北企业建站系统平台,网络推广培训资料,做网站的框架,杭州网站建设出 名Rocksdb的优劣及应用场景分析
Rocksdb也是一样#xff0c;也有它的优势劣势及特定的适用场景。今天我就从设计的角度来分析一下。
基础架构 上图就是Rocksdb的基础架构。Rocksdb中引入了ColumnFamily(列族, CF)的概念#xff0c;所谓列族也就是一系列kv组成的数据集。所有…
Rocksdb的优劣及应用场景分析
Rocksdb也是一样也有它的优势劣势及特定的适用场景。今天我就从设计的角度来分析一下。
基础架构 上图就是Rocksdb的基础架构。Rocksdb中引入了ColumnFamily(列族, CF)的概念所谓列族也就是一系列kv组成的数据集。所有的读写操作都需要先指定列族。写操作先写WAL再写memtablememtable达到一定阈值后切换为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.大规模数据的存取 作者从此启航 链接https://www.jianshu.com/p/73fa1d4e4273 来源简书 著作权归作者所有。商业转载请联系作者获得授权非商业转载请注明出处。
