rocksdb写放大_谈谈 RocksDB 参数调优

背景

RocksDB是由Fackbook公司开源的一款性能很高的Key Value存储引擎，有很多项目包括58存储团队的分布式KV存储产品WTable都使用它作为存储引擎。但是RocksDB参数调优也极其复杂，若希望RocksDB在不同机器、不同的应用场景发挥良好的性能，并不是一个简单的事情。绝大多数时候在一台机器或者一个集群中调整的参数，在另一个机器或集群中性能可能会不行。在RocksDB官网中，已经提供一篇关于调优的wiki，RocksDB Tuning Guide以供大家参考。这里笔者会结合58存储项目的一些些使用经验，详细对其解释，和大家一起学习。在优化RocksDB参数前，首先应该先了解RocksDB是如何具体处理LSM的。这个在其他公众号应该有很多文章了，这里暂时不重复说明了，有机会可能会加入这方面的内容。

放大因素

调试RocksDB通常是在三个Amplifcation之间进行取舍：

1. 写放大。目前我们最常碰见的是写放大。假如我们写入10M的数据，但是实际上硬盘写入30M数据，那么写放大就是3。如果是写入压力较大的机器或者集群，我们就需要尽量减小写放大。通过RocksDB本身的统计可以观察。

2. 读放大。每次请求需要读几次硬盘。如果一个query需要读5 pages，那么读放大就是5。在RocksDB本身的统计中并没有特别好的方法去观察读放大，通常需要iostat等命令来评估。

3. 空间放大。假如需要存储10M数据，实际上硬盘占用100M，那么空间放大就是10。

RocksDB 统计信息

我们实际调优性能时，绝大多数都是借助RocksDB本身的统计信息。RocksDB有个参数stats_dump_period_sec可以定时将这些stats信息打印到LOG日志 中，默认是10分钟。也可以通过db->GetProperty("rocksdb.stats")直接在程序中获得统计信息。目前，WTable只使用默认的Column Family，统计信息如下：

上面是默认Column Family的compaction统计信息，以及整个DB的统计信息。

Compaction 信息

Compaction stats就是Level N和N+1做compaction的一些数据统计，在N+1输出结果：

• Level 就是LSM的level。Sum代表所有level的总和。INT是从上次打印到现在的数据。
• Files 有两个值a/b。前者是每层Level的文件个数，后者是当前有多少个文件正在compaction。
• Size 当前Level的大小。
• Score 除了Level-0，score值是(current level size) / (max level size)。正常情况下值是0或者1，如果大于1，则代表这层Level需要compaction。对于Level-0的score值计算方式是(current number of files)/(number of compaction trigger)。
• Read(GB) 是从Level N到N+1做compaction的总读取数据量。
• Rn(GB) 是从Level N到N+1做co