首页
学习
活动
专区
工具
TVP
发布

PebblesDB读后感

SOSP2017[1]于10月底在上海举办,因为离得比较近,笔者也去参加学习了一下。会议上的大部分文章都相当的务实,有的甚至可以直接辅助工程实践,比如将要分享的PebblesDB[2]。

10年前Google发表BigTable[3]的论文,推动了基于LSM的KV系统架构的流行,而随着KV系统的应用面超越NoSQL数据库走向越来越广阔的领域,LSM的写放大问题也越来越成为系统稳定的一个阻碍。在LevelDB/RocksDB这种分层思路上,PebblesDB提出了一种减少写放大的思路,下面学习并总结,所述以论文为基础,也有个人观点,客观论述请看原文。

虽然LSM的写放大最近被研究很多,但是就写放大本身而言,是一个很古老的问题。在计算机体系中,如果相邻两层的处理单元不一致或者应用对一致性等有特殊的需求,就很可能出现写放大问题。比如CPU cache和内存cell,文件系统block和磁盘扇区,数据库block和文件系统block,数据库redo/undo,文件系统journal等。文中对写放大给了一个明确的定义,就是用户写入数据和系统写入数据的反比,比如用户写了1M,系统在稳定之后一共向存储设备写出10M,那么放大系数就是10。一些熟知的系统,其放大系数可能超越我们的想象,见下图1(如无特殊说明,图片均来自论文[2])

图1 几款流行KV的放大系数对比

RocksDB放大系数高达42倍,LevelDB也高达27倍,不看绝对数字,只看趋势的话,还是符合直觉的,毕竟RocksDB做了不少加速compaction的功能优化。本文的PebblesDB做的不错,但是仍然超过了10。写放大意味着更多的读写,会造成系统波动,对比如SSD来说会加速寿命衰减,从成本角度说也更加耗电,所以解决写放大就成了一个很重要的问题。我们看这张图的时候,理解放大很严重就可以了,具体数字不必计较,现实中当然有很多针对具体业务的办法把放大控制在一定范围。

作者分析了LevelDB/RocksDB使用的分层结构,认为有一个关键问题导致了其写放大很严重,即L0层数据可能跟Lx层全range交叠。图2很好的说明了这个问题。

图2 解释传统分层模型写放大的原因

图2显示,L0文件里面包含的key同时在L1层的多个文件(甚至全部文件)被包含,所以如果想把L0下推到L1,那么就需要将整个L0/L1文件内的key读出来重新排序写入到L1。典型情况下,L0数据量是L1的1/10,为了这么点数据量重写所有数据显然不划算。L1...Ln道理类似。

思考问题的本质有助于判断终极解决方案,放大问题的本质是一个系统对“随时全局有序"的需求有多么的强烈。所谓随时,就是任何的写入都不能导致系统无序;所谓全局,即系统内任意元单位之间都要保持有序。B-Tree系列是随时全局有序的典型代表,而Fractal tree打破了全局的约束,允许局部无序,提升了随机写能力;LSM系列进一步打破了随时的约束,允许通过后台的compaction来整理排序。在LSM这种依靠后台整理来保序的系统里面,系统对序的要求越强烈,写放大越严重。

PebblesDB针对写放大提出的解决方案是弱化全局有序的约束,其将每一层进行分段,每个段称为一个guard,guard之间没有重叠的key,且每层的guard之间要求保序,但是guard内部可以无序。这个跟skiplist的思路非常像,所以作者说是从skip list借鉴了思想,见图3。

图3 PebblesDB 关键思路

图3看起来确实很像一个skiplist,guard如果在上一层存在,那么下面所有层都存在;同层相邻guard之间无交叠(L0数据少,没有guard)。如前面分析,分层组织结构导致写放大的原因是Li在下推数据的时候跟整个Li+1是重叠的,所以导致所有Li和Li+1的数据都要重写,这显然增加了写放大。而这里将Li和Li+1分为多个guard,那么当Li层数据需要下推的时候,不再是整个Li一起下推,而是可以按照guard为单位来进行,那些基本没有数据变化的guard就不用下推了。在guard下推的过程中,另外一个属性进一步减少了写放大,那就是guard内文件之间不必有序,这样有些文件可能不需要读取,直接move过去就可以了。很奇妙!结果当然也不错,显著减少了写放大,见图4。

图4 PebblesDB 基于guard的思路减少写放大

图4显示,在三个级别的数据规模上,PebblesDB都获得了较低的放大系数,典型对比甚至降低一倍以上。文中还有非常多方面的对比,学术论文的考虑周全、测试严谨是非常值得学习的。

通读全文来看,该思路减少写放大还是比较容易理解的,因为削弱了全局序。当然代价就是scan的时候变差了,因为scan天生对序有强烈的依赖,作者提到可以通过提高IO并发等缓解scan性能的下降。文字还提到了guard带来的其他好处,比如compaction的并行度变大了,每个guard所代表的相邻层可以独立进行compaction以及guard的选择、空guard的处理问题。

[1]. SOSP2017: https://www.sigops.org/sosp/sosp17/program.html

[2]. PebblesDB: Building Key-Value Stores usingFragmented Log-Structured Merge Trees

[3]. BigTable: http://research.google.com/archive/bigtable-osdi06.pdf

[4]. LevelDB: https://github.com/google/leveldb

[5]. RocksDB: https://github.com/facebook/rocksdb/

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20171221G0G95H00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券