4 ms·
I think you're backwards. Random writes are LSM trees' forte because they can batch them. Sequential writes would be doable with a b-tree.
by btrask 11y ago
I think you're backwards. Random writes are LSM trees' forte because they can batch them. Sequential writes would be doable with a b-tree.
- hyc_symas 11y agoBatching doesn't help the write amplification from compaction. Read the doc. http://leveldb.googlecode.com/svn/trunk/doc/impl.html http://leveldb.googlecode.com/svn/trunk/doc/impl.html Do the math.
- btrask 11y agoWrite amplification is not the only thing that matters. For small keys, higher write amplification is a good tradeoff for doing less seeks (which yes, are still a performance problem on SSDs, probably because of the block size). For large keys, I agree with you, you shouldn't use an LSM-tree. There is a threshold between seek time and compaction.
- hyc_symas 11y agoIn the InfluxDB workload, they didn't get the "less seeks" you're talking about. Sure, you can delay paying for the seek by a second, if that. So can the buffer cache on any other DB structure. But when you have an overlapping range of keys and it's continuously growing, you hit the worst-case. Which InfluxDB did.