LSM 优化系列（六）-- 【ATC‘20】MatrixKV : NVM 的PMEM 在 LSM-tree的write stall和写放大上的优化

文章目录

LSM 问题背景
MatrixKV 设计细节
- 整体架构介绍
- Matrix Container介绍
- - Receiver
  - RowTable
  - Compactor
  - Space management
- Column Compaction介绍
- 对于Column Compaction的总结
- 读加速 Cross-row Hint Search
- MatrixKv 写入完整流程
- MatrixKV 读取完整流程
MatrixKV 性能
总结

这篇论文大家可能不了解，但是"华为天才少女年薪150w" 那个热搜女孩大家应该听过。这里分享的这一篇论文是ATC’20 存储技术相关的顶会今年收录的一篇，她是一作；去年她的一篇GearDB: A GC-free Key-Value Store on HM-SMR Drives with Gear Compaction 被FAST’19 收录，她也是一作。

她之前的相关论文并没有再搜，但从这两篇顶会以一作的身份来看，她本身的实力不言而喻。存储技术的顶会大家可以看看相关的官网数据，国内被录入的基本都是顶级互联网公司级的团队产出以及知名教授带领的C9 top学校团队。她以一作贡献最大的身份被录入，这样的年薪是实至名归的（国内还是需要留住优秀人才的）。

当然，她所做的技术是数据库/存储相关的，同样是TOP级公司极为看重的核心技术，也才会有这样的优质待遇。

回到今天要讨论的论文 : MatrixKV:Reducing Write Stalls and Write Amplification 上。

ps：本篇并非论文翻译，下文的组织形态是比较简化的，感觉可能会有信息缺失的同学可以直接看论文。
该论文是基于 rocksdb 5.18.3 版本实现的，源代码MatrixKV-github

关于rocksdb compaction的一些基础知识可以参考这两篇。这是详解，会涉及到源码层级的分析。
1. SST文件详细格式源码解析
2. Compaction 完整实现过程概览

LSM 问题背景

本篇论文关注的问题背景是LSM-tree 带来的 write-stall 以及写放大问题。
都是针对LSM的老生常谈的问题，关于write-stall 直接参考SILK- Preventing Latency Spikes in Log-Structured Merge Key-Value Stores 中的Latency Spike 在LSM-tree中的体现即可。

其中Write-Stall的主体原因还是I/O资源的竞争，Higher-level compaction 与更高优先级的Flush和L0->L1 compaction的I/O资源进行竞争，导致更高优先级的internal 操作无法及时完成，最终体现在客户端的操作就是Write-stall或者高长尾延时。而造成write-stall 的主体compaction就是 L0->L1 的compaction过程，这个过程L0重复的key最多，但却只有一个compaction 线程来做（传统LSM 在更高层中 sst文件之间以及之内不允许又重叠key），所以效率也很低，这就在大压力的场景下很大概率造成write-stall。

写放大问题简要概述一下，在PebblesDB Building Key-Value Stores using FLSM-Tree(Fragmented) 中的背景描述也有说。
如下图

L1->L2 compaction的过程中，选择一部分L1的sst文件，一部分L2的sst文件，compaction之后又写入到了L2；这样下一次又调用的 L1->L2 的compaction 可能又会将之前的写入的sst文件的key-value读出来，重新合并排序，再次写入到L2。这样，很多key-value不断的被读写，而自己本身并没有发生变化。随着LSM 层数的增加，读写放大的比例会越来越大 WAM = AF *n（wam 是写放大的倍数，AF是写放大的系数，n是LSM的层数）。

这就是在Level compaction过程中出现的读写放大，带宽资源有限的情况下用户态吞吐会被严重限制。

MatrixKV 的出现背景就是想要在Write stall 和写放大上进行一些优化，重心需要放在L0->L1的compaction速度慢问题之上。直接办法是变更存储介质（NVM-PMEM），只变更存储介质，仍然会有write-stall的问题，毕竟L0->L1 compaction速度提升不上来。这里我比较好奇的是论文中并没有提到subcompaction机制，rocksdb的subcompaction机制本身也是在L0->L1 compaction速度慢的情况下按照sst文件粒度拆分成多个compaction线程并发来做。

总之，只变更存储介质为更高性能的（NVM-PMEM）是不够的，论文中有Novel-LSM 的数据可以看到还是有大量write-stall。所以还需要变更L0->L1的数据结构，实现算法层的加速。至于，降低写放大，通过这个公式 WAM = AF *n，论文中直接将 Level层数减少，比如原来的6层，减少为4层，并增大每一层的容量（这个优化略显尴尬