RocksDB dynamic-level-bytes参数测试记录

Rocksdb的leveled compaction 有2种计算level target size方式：第一种是静态计算方式，根据max-bytes-for-level-base和max-bytes-for-level-multiplier从L1层逐层往下按倍数计算每层target size。第二种是动态计算方式需开启dynamic-level-bytes参数，以最后一层实际大小为base，逐层向上计算每层target size，数据主要写入最后一层和最后-1层，前面会有部分层没有数据，大约有90%数据在最后一层。

因为delete后的数据要到最后一层后才能被真正清理，因此动态模式下能更快的完成delete数据清理，减少空间放大，理想状态下动态计算方式空间放大可达到1.11倍。

       本文简单记录dynamic-level-bytes在开启和关闭状态下的2个tikv集群测试结果供大家参考，dynamic-level-bytes相关内容可阅读：https://github.com/facebook/rocksdb/blob/v3.11/include/rocksdb/options.h#L366-L423 。   compaction相关 内容可阅读官方文档 https://github.com/facebook/rocksdb/wiki/Compaction或https://tidb.net/blog/eedf77ff 。

1、 测试环境

       2套v6.3.0集群初始化时分别设置dynamic-level-bytes为true(3.0版本后默认为true)和false，保持默认gc设置。使用sysbench 初始化10张1亿条记录的表，之后使用128线程连续3次压测记录TPS/平均延迟，每项压测10分钟。

2、初始化后tikv大小

以下截图为完成初始后14小时后截图，期间未进行任何操作。

       dynamic-level-bytes: true，总空间大小为402.9G。

       dynamic-level-bytes: false，总空间大小为599.8G。

3、 各层sst文件数量

dynamic-level-bytes: true，数据主要写入了writecf，集中在leve 6/5 两层，level 1/2层没数据。

       dynamic-level-bytes: false，数据主要写入了writecf，集中在leve 4/3 两层，level 5层没数据。

4、sysbench 压测

       从每次压测结果对来看dynamic-level-bytes为true时TPS/平均延迟均好于参数为false时。(可能压测时间延长指标会有变化)

4、压测期间各层文件变化

dynamic-level-bytes: true时压测期间6/5层sst文件均有明显减少，从4.24k/1.04k左右降到3.69k/0.97K左右。

       dynamic-level-bytes: false时压测期间4层文件数有一定增高，由压测前4.45k左右增加到4.51k，最终结束是回落到4.27K，相比动态方式sst文件减少不大。

5、压测结束3小时后sst文件数量

      dynamic-level-bytes: true（压测结束时间11:56），最终4/5/6层文件数为4.81K

       dynamic-level-bytes: false（压测结束时间14:36），压测结束后由于compaction sst file逐渐减少，最终2/3/4层文件数为5.0K

7、tikv 手动compact测试

设置dynamic-level-bytes: true、GC safe point为24h避免compaction-filter影响，delete一张表的全部数据，待各层sst文件稳定后手动在线对tikv进行compact，命令如下,相关参数可参考官方文档： tikv-ctl --host xxxxxx:20160 compact --bottommost force -c write -d kv

       可以看到delete期间各层sst file有一定增长，手动compact时6层以下文件逐渐降低。

Delete期间的compact和手动compact的速率，手动compact的默认并发--threads=8，生产中避免影响时可降低该参数值。

SST文件读写延迟对比：

查询表中数据，确认delete是否被GC。