Show HN: CaskDB – project to teach you building a key value store
github.com
github.com
CaskDB is based on Riak's Bitcask paper. The idea of Bitcask is brilliant yet straightforward, which makes it attractive for newbies to learn about key-value store internals and implement one.
I have set up this project in TDD fashion with the tests. So, you start with simple functions, pass the tests, and the difficulty level goes up. There are hints if you get stuck (e.g. https://github.com/avinassh/py-caskdb/blob/e0819f7/format.py...). When all the tests pass, in the end, you would have written a persistent key-value store.
I had great fun implementing this, and I hope you do too. And I hope this makes you dig deep into the fantastic world of database engineering.
> None of the local key/value storage systems available were ideal with regard to all of the above goals. We were discussing this issue with Eric Brewer when he had a key insight about hash table log merging: that doing so could potentially be made as fast or faster than LSM-trees.
(from the paper)
> That whole experiment sent me on a different career trajectory - and was key to me switching from Devops/SRE style career path to a dev path
How did it go? Do you have any suggestions/insights to share? I am also hoping to make a career transition from backend dev to database dev down the line.
The introductory whitepaper on bitcask's design is here: https://riak.com/assets/bitcask-intro.pdf
- 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-...
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.
> 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.
Nit: Typo in the hyperlink to the paper.