{"type":"rich","version":"1.0","provider_name":"Transistor","provider_url":"https://transistor.fm","author_name":"Programming Tech Brief By HackerNoon","title":"Benchmarking RocksDB’s Three Amplification Factors","html":"<iframe width=\"100%\" height=\"180\" frameborder=\"no\" scrolling=\"no\" seamless src=\"https://share.transistor.fm/e/f2a17c71\"></iframe>","width":"100%","height":180,"duration":840,"description":"\n        This story was originally published on HackerNoon at: https://hackernoon.com/benchmarking-rocksdbs-three-amplification-factors.\nFour RocksDB experiments show how deletes, key order, Bloom filters and compaction I/O distort read, write and space amplification.\nCheck more stories related to programming at: https://hackernoon.com/c/programming.\n            You can also check exclusive content about #rocksdb, #lsm-trees, #database-benchmarking, #write-amplification, #read-amplification, #rocksdb-compaction, #space-amplification, #hackernoon-top-story,  and more.\nThis story was written by: @hackermuksh2690. Learn more about this writer by checking @hackermuksh2690's about page,\n            and for more stories, please visit hackernoon.com.\nRocksDB benchmarks show that deletes can increase disk usage, L0 files can raise lookup latency and sequential keys can conceal write amplification. The larger lesson is that key distribution, system load and compaction capacity matter more than any isolated configuration knob.","thumbnail_url":"https://img.transistorcdn.com/KhCapPSRkLGL2Xw8888yuChkNRWthaKapLYTvNdu4W4/rs:fill:0:0:1/w:400/h:400/q:60/mb:500000/aHR0cHM6Ly9pbWct/dXBsb2FkLXByb2R1/Y3Rpb24udHJhbnNp/c3Rvci5mbS9zaG93/LzQxMTY2LzE2ODM1/ODIzMzAtYXJ0d29y/ay5qcGc.webp","thumbnail_width":300,"thumbnail_height":300}