The used synthetic benchmark is not a great indicator of performance in most (any?) production environments. It's generally useful and interesting to understand the tradeoffs between an LSM and B-Tree. Particularly, if you have an update or delete heavy workload the compaction cost of an LSM can become an issue. B-Tree's don't suffer from compaction issues, so in some sense trade consistently slower writes instead of amortizing out an I/O intensive compaction.
Some of the worst production experiences I've had came from exhausting I/O on the database, and then having LevelDB / RocksDB / LSM stores kick off their compaction. B-Tree will give you a very consistent redline in terms of performance generally.
TL;DR: There are trade offs between the two, but this benchmark is not particularly insightful given that it doesn't really test any of the interesting boundary conditions or real world query patterns.
Some of the worst production experiences I've had came from exhausting I/O on the database, and then having LevelDB / RocksDB / LSM stores kick off their compaction. B-Tree will give you a very consistent redline in terms of performance generally.
TL;DR: There are trade offs between the two, but this benchmark is not particularly insightful given that it doesn't really test any of the interesting boundary conditions or real world query patterns.