4 ms·
I hadn't heard about bitcask before. Its design looks like a great alternative to LSM trees or B+trees like lmdb. Are there any good benchmarks comparing the ap
by josephg 5y ago
I hadn't heard about bitcask before. Its design looks like a great alternative to LSM trees or B+trees like lmdb. Are there any good benchmarks comparing the approaches?
The introductory whitepaper on bitcask's design is here: https://riak.com/assets/bitcask-intro.pdf https://riak.com/assets/bitcask-intro.pdf
- avinassh 5y agoI am not aware of any benchmarks with rocksdb (LSM) or lmdb (b-tree), but theoretically it will be much faster at the cost of extra RAM - In Bitcask, reads have at most single seek. Writes are just append - LSM - writes are just append, but reads are slower. Like in rocksdb, it has to check multiple files for the key - B Tree - both read/writes require multiple seeks Bitcask is that middle ground gives best of both, but takes up more RAM since it has to store all the keys. Riak also provides a memory calculator - https://docs.riak.com/riak/kv/latest/setup/planning/bitcask-capacity-calc/index.html https://docs.riak.com/riak/kv/latest/setup/planning/bitcask-...
- josephg 5y agoThe other downside of Bitcask is that it requires periodic compaction operations to avoid continuously increasing disk utilization. LSM trees and B+Trees do this work "on the fly". I'm not sure how big a downside that is in practice, but it might be unfair to compare lmdb or rocksdb with bitcask if bitcask is never compacting.
- avinassh 5y agoLSM also requires periodic compaction, right? > I'm not sure how big a downside that is in practice, but it might be unfair to compare lmdb or rocksdb with bitcask if bitcask is never compacting. Bitcask also does compactions, they call it merge. It is mentioned in the paper too, but not much in detail.