Benchmarking RocksDB’s Three Amplification Factors

RocksDB, an LSM-tree database, features three amplification factors: space amplification, read amplification, and write amplification. While tuning for optimal performance is difficult, the database developers discourage relying on benchmarks and instead advocate for experiments and measurements considering these amplification factors.

One experiment measured the impact of deleting half the keys on disk usage. Initially, the database contained 1,000,000 keys amounting to 107.8 MB of logical data and 111.5 MB on disk (1.04× space amplification). After deleting every other key, live data decreased to 53.9 MB, while disk usage spiked to 127.6 MB (1.58× space amplification).

This sawtooth pattern results from compaction passes reclamation space and tombstones accumulating faster than compaction retiring them. A full compaction afterward restored disk usage to 56.0 MB for 53.9 MB of data (1.04×).

Another test examined the impact of L0 file count on lookup latency. With auto-compaction disabled, each L0 file increased get() latency by roughly 0.96 µs per file. Enabling bloom filters reduced latency to 2.54 µs. These results demonstrate that bloom filters are critical to maintaining acceptable lookup times despite increasing L0 file count.

A subsequent experiment looked at write amplification for random versus sequential key writes. Writing 2,000,000 keys resulted in 982 MB of disk writes for 216 MB of data (4.56× write amplification) with random keys. Sequential key writes, however, only required a 1.03× write amplification, showcasing the optimization of bulk-loading sorted data into RocksDB. This highlights the importance of key order in write amplification and the trap of assuming RocksDB write performance will remain constant across different workloads.