https://github.com/isubasinghe/bitdb

Implementation of the bitcask paper
https://github.com/isubasinghe/bitdb

Last synced: 26 days ago
JSON representation

Implementation of the bitcask paper

• Host: GitHub
• URL: https://github.com/isubasinghe/bitdb
• Owner: isubasinghe
• Created: 2022-05-08T14:44:30.000Z (over 2 years ago)
• Default Branch: main
• Last Pushed: 2022-11-15T05:08:17.000Z (almost 2 years ago)
• Last Synced: 2023-03-04T01:55:07.346Z (over 1 year ago)
• Language: Rust
• Homepage:
• Size: 27.3 KB
• Stars: 0
• Watchers: 2
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# bitdb

## Performance 

As expected on such a performance oriented (memory based) database, I was able to get 100,000 inserts in just 600ms. 

## TODO 

  * Migrate to CTrie or HAMT based on Ideal Hash Trees paper for in memory store 

  * This implementation can be used to support prefixes in keys by making slight modifications in how the insertion/search process works. Prefixes of keys are important because we can use this for searching by prefix

## Notes 

### CTrie 

Writing a ctrie is not that difficult, we only need to perform CAS operations on hash slots. I do not believe the CAS traversals (for insertion/search) should impact correctness but we should probs yield via futures instead of spinning. 

But the more relevant question could be do we even need to make this concurrent? file IO is needed before we can write to the in memory data structure, file IO is likely to overshadow anything else. 

Perhaps if our persisted data layout was more complex, CTries may make sense, but insertions and reads are a single seek/(read|write) pair.

## Resources 

  * [Riak bitcask paper](https://riak.com/assets/bitcask-intro.pdf)

  * [Ideal Hash Trees](http://lampwww.epfl.ch/papers/idealhashtrees.pdf)