lsm-tree延迟分析
- L0满， 无法接收 write-buffer不能及时Flush，阻塞客户端
- 高层压缩占用IO
- L0 L1压缩慢
- L0 空间少
- Flush 太慢，客户端阻塞 -> rate limiter限速
rocksdb的解决方案就是rate limiter限速
slik思路
（1）优先flushing和lower levels的compaction，低level的compaction优先于高level的compaction，这样保证flushing能尽快的写入level 0，level 0尽快compaction level 1，（a）尽量避免因为memtable到达上限卡client I/O，（b）尽量避免因为level 0的sstable文件数到达上限卡client I/O。实际实现的时候会有一个线程池专门用于Flushing；另外一个线程池用于其他的Compaction
（2）Preempting Compactions：支持抢占式Compaction，也就是高优先级的compaction可以抢占低优先级的compaction，也就是说另外一个用于L0~LN之间的compaction的线程池，优先级高的low level compaction可以抢占high level的compaction，这样L0->L1在这个线程池，最高优先级的compaction就能够在必要的时候抢占执行，保证尽量不会出现level 0的sstable数量超过阈值
（3）在low load的时候，给Internal Operation（compaction）分配更多的bandwidth，相反，在high load的时候，给Client operation分配更多的带宽，这样可以保证Compaction在适当的时候也能得到更多的处理，减少read放大和空间放大，这个调度策略也是基于通常的client operation load是波动这事实来设计的，如下图，就是一个真实环境的workload变化规律：
ref
- https://blog.csdn.net/Z_Stand/article/details/109683804
- https://zhuanlan.zhihu.com/p/77543818
- 论文地址 https://www.usenix.org/system/files/atc19-balmau.pdf
