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来说会加速寿命衰减，从成本角度说也更加耗电，所以解决写放大就成了一个很重要的问题。我们看这张图的时候，理解放大很严重就可以了，具体数字不必计较，现实中当然有很多针对具体业务的办法把放大控制在一定范围。