RocksDB调优指南

最新推荐文章于 2023-10-19 16:57:49 发布

john-zeng

最新推荐文章于 2023-10-19 16:57:49 发布

阅读量1w

点赞数 6

分类专栏：数据库文章标签： rocksdb

本文原味来自rocksdb的英文wiki。翻译后放在了我的repo中rocksdb-doc-cn，此处只做简单转发，并且原文没有做任何校对，欢迎提修改意见。希望能帮助到有需要的朋友

下面是正文?

本指南的目的是提供你足够的信息用于根据自己的工作负载和系统配置调优RocksDB。

RocksDB非常灵活，这有好也有坏。你可以真多很多工作场景和存储技术进行调优。在Facebook，我们使用相同的代码跑内存工作压力，闪盘设备和机械硬盘。然而，灵活性不总是对用户友好的。我们引入了大量的调优参数，让人疑惑不解。我们希望这个指南会帮助你压榨你的系统的最后一滴性能并且完全利用你的资源。

我们假设你有一定的基础知识，了解LSM工作原理。关于LSM的资源非常多，不需要再写一个了。

放大因子

调优RocksDB通常就是在三个放大因子间做权衡：写放大，读放大，和空间放大。

写放大是写入磁盘的数据与写入数据库的字节数的比。

例如，如果你写入 10MS/s 到数据库，然后你观察到硬盘写速度为30MB/s，你的写放大为3.如果写放大很高，工作负载的瓶颈可能在磁盘吞吐。比如，如果写放大是50，而磁盘吞吐是500MB/s，你的数据库只能达到10MB/s的写速度。在这种情况下，减少写放大会直接增加最大写速率。

高写放大同时减少闪存使用寿命。有两个方式你可以观察到写放大。第一个方式是读取DB::GetProperty("rocksdb.stats", &stats)的输出。第二个是使用你的DB写速率除以你的磁盘写带宽。

读放大是每秒磁盘读的数量。如果你需要读5个页来响应一个查询，读放大就是5。逻辑读是从缓存得到的数据，要么从Rocksdb的块缓存，要么从OS的文件缓存。物理读通过存储设备，闪存或者硬盘，处理。逻辑读比物理读便宜很多，但是会导致CPU开销。你也可以通过iostat的输出估算读放大，但是这个结果包含了查询和压缩的读。

空间放大是数据库磁盘上的文件的大小和数据大小的比。如果你Put 10MB的数据到数据库，它使用了100MB的磁盘，那么空间放大为10.你通常希望设置一个硬性限制给空间放大，这样你就不会吧磁盘空间或者内存用光了。

为了了解这三个放大因子在不同数据库算法下的情况，我们强烈推荐Mark Callaghan关于高并发的演讲

Rocksdb统计

当调试性能的时候，有一些工具可以帮助到你：

statistics —— 把这个设置给rocksdb::CreateDBStatistics()。任何时候，通过调用options.statistics.ToString()，你可以得到一个人类可读的Rocksdb统计信息。参考统计了解更多信息。

stats_dump_period_sec ——我们每stats_dump_period_sec秒就会把统计信息导出到日志文件。默认为600，意味着每10分钟导出一次。你可以在应用里调用db->GetProperty("rocksdb.stats")得到相同的数据。

每db->GetProperty("rocksdb.stats")，你会在日志文件里找到这样的数据：

** Compaction Stats **
Level Files  Size(MB) Score Read(GB)  Rn(GB) Rnp1(GB) Write(GB) Wnew(GB) Moved(GB) W-Amp Rd(MB/s) Wr(MB/s) Comp(sec) Comp(cnt) Avg(sec) Stall(sec) Stall(cnt) Avg(ms)     KeyIn   KeyDrop
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
L0      2/0        15   0.5     0.0     0.0      0.0      32.8     32.8       0.0   0.0      0.0     23.0    1457      4346    0.335       0.00          0    0.00             0        0
L1     22/0       125   1.0   163.7    32.8    130.9     165.5     34.6       0.0   5.1     25.6     25.9    6549      1086    6.031       0.00          0    0.00    1287667342        0
L2    227/0      1276   1.0   262.7    34.4    228.4     262.7     34.3       0.1   7.6     26.0     26.0   10344      4137    2.500       0.00          0    0.00    1023585700        0
L3   1634/0     12794   1.0   259.7    31.7    228.1     254.1     26.1       1.5   8.0     20.8     20.4   12787      3758    3.403       0.00          0    0.00    1128138363        0
L4   1819/0     15132   0.1     3.9     2.0      2.0       3.6      1.6      13.1   1.8     20.1     18.4     201       206    0.974       0.00          0    0.00      91486994        0
Sum  3704/0     29342   0.0   690.1   100.8    589.3     718.7    129.4      14.8  21.9     22.5     23.5   31338     13533    2.316       0.00          0    0.00    3530878399        0
Int     0/0         0   0.0     2.1     0.3      1.8       2.2      0.4       0.0  24.3     24.0     24.9      91        42    2.164       0.00          0    0.00      11718977        0
Flush(GB): accumulative 32.786, interval 0.091
Stalls(secs): 0.000 level0_slowdown, 0.000 level0_numfiles, 0.000 memtable_compaction, 0.000 leveln_slowdown_soft, 0.000 leveln_slowdown_hard
Stalls(count): 0 level0_slowdown, 0 level0_numfiles, 0 memtable_compaction, 0 leveln_slowdown_soft, 0 leveln_slowdown_hard

** DB Stats **
Uptime(secs): 128748.3 total, 300.1 interval
Cumulative writes: 1288457363 writes, 14173030838 keys, 357293118 batches, 3.6 writes per batch, 3055.92 GB user ingest, stall micros: 7067721262
Cumulative WAL: 1251702527 writes, 357293117 syncs, 3.50 writes per sync, 3055.92 GB written
Interval writes: 3621943 writes, 39841373 keys, 1013611 batches, 3.6 writes per batch, 8797.4 MB user ingest, stall micros: 112418835
Interval WAL: 3511027 writes, 1013611 syncs, 3.46 writes per sync, 8.59 MB written

压缩信息

在level N和level N+1之间执行的压缩流程的压缩信息会在level N+1处（输出层）进行汇报。这里是一个快速参考：

level —— leveled压缩在LSM中的层。对于universal压缩，所有文件都在L0.Sum有所有层的数据的和。Int类似于Sum但是只限于从上一次汇报之后的间隔之间的数据。
Files —— 他有两个如(a/b)的数值。第一个数字是这一层的文件数量。第二个是当前该层正在进行压缩的文件的数量。
Score —— 除了L0之外的层，score是（当前层大小）/(最大层大小)。值为0或者1都是正常的，但是如果值大于1，意味着这个层需要被压缩。对于L0，score根据当前文件的数量和触发压缩的文件数量来计算。
Read(GB) —— 在level N和level N+1之间压缩的时候读取的总字节数。这包括了从level N和level N+1读取的数据。
Rn(GB)：在level N和level N+1之间压缩的时候，从Level N读取的字节数。
Rnp1(GB)：在level N和level N+1之间压缩的时候，从Level N+1读取的字节数。
Write(GB)：在level N和level N+1之间压缩的时候写出的总字节数。
Wnew(GB)：写到level N+1的新字节数，计算方式为：(写到N+1的总字节数) - (与level N 压缩的时候，从N+1读取的字节数)
Moved(GB)：压缩期间移动到Level N+1的字节数。这个场景下，没有任何