4 ms·
I 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 hav
by avinassh 4y ago
I 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 4y 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 4y 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.