从 CPU 来看，Compaction 期间 RocksDB 6.x 波动范围

从 CPU 来看，Compaction 期间 RocksDB 6.x 波动范围比较大，波谷主要是由于 6.x 的 Compaction 和写入有锁竞争导致 CPU 利用率急剧下降，而 7.x 几乎没有波动。同时，最后一段时间停掉写之后，7.x 的 Compaction 的 CPU 利用率也比 6.x 少 40% 左右。

OPS 对比

从 OPS 的对比来看， RocksDB 6.x 的 OPS 波谷和 CPU 几乎是一致的，Compaction 期间可能会几乎掉到 0，而 7.x 则是十分稳定。

延时对比

同样，RocksDB 6.x 的延时在 Compaction 期间也会有剧烈的波动，而 RocksDB 7.x 则表现十分平稳，甚至低到在对比图中几乎看不到。

为了可以更清楚看到 7.x 的延时情况，下图把 RocksDB 6.x 去掉，可以看到新版本的延时几乎没有波动。

Compaction 耗时对比

同样的数据量，RocksDB 7.x 会比 RocksDB 6.x Compaction  的持续周期会更长一些。说明了 RocksDB 7.x 除了锁优化之外，也将后台的 Compaction 相关的周期拉得更长来规避影响正常的读写请求。

其他关键指标

从 Estimate Keys 数量以及 DB 大小来看，两个版本存储的数据量比较接近，整体上符合预期。

磁盘读写也印证了 RocksDB 7.X 在 Compact 策略上会比 6.x 更加缓和，从本次测试结果来看几乎对于实时读写没有造成任何影响。

总结

从以上单次的压测数据来看，RocksDB 7.x 版本的 Compaction 几乎没有对写入造成太大影响。主要优化来自两方面:

• RocksDB 修复了 Compaction Pending Bytes 计算放大问题导致长时间 Write Stall 问题，具体讨论见:  rocksdb #issue 9423
• 减少了 Compaction 和写入的锁竞争，从而规避了 Compaction 期间阻塞写入问题