背景
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