Rocksdb dynamic-level-bytes 测试简单记录

2022-10-21
北京
本文字数：2033 字
阅读完需：约 1 分钟

作者： h5n1 原文来源：https://tidb.net/blog/7f8aeedb

    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。

              ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1665999785225.png)

复制代码

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

              ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1665999793465.png)

复制代码

3、各层 sst 文件数量

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

     ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1665999801790.png)

复制代码

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

   ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1665999821863.png)

复制代码

4、sysbench 压测

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

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

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

        ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1665999840141.png)

复制代码

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

       ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1665999847539.png)

复制代码

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

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

       ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1665999860731.png)

复制代码

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

     ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1665999868888.png)

复制代码

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，生产中避免影响时可降低该参数值。

                          ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1666153918553.png)
   SST文件读写延迟对比：
                        ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1666154559309.png)
   查询表中数据，确认delete是否被GC。
                          ![image.png](https://tidb-blog.oss-cn-beijing.aliyuncs.com/media/image-1666154328190.png)

复制代码