Show HN: Dbeel – A distributed thread-per-core db (github.com)
For a while now I had the urge to learn how to pick the "right" database for projects, I looked around online at different databases to try to understand their different traits, and was bombarded with marketing instead of actual info on the advantages and drawbacks.
The only solution for me was to learn some database internals (I read the wonderful book written by Alex Petrov), and the problems seemed so interesting, I could not fight the urge and went ahead with trying to write my own db.
Anyway, ~9 months have passed and I feel like I'm "done", I have learned a ton, and really proud of dbeel.
Now I can pick a database and way more easily understand what are its most defining traits.
Some short time in the future, I will release a blog post or something, where I will write about the fundamental problems you need to solve when writing a performant data system like a database, so stay tuned :)
16 comments
[ 4.3 ms ] story [ 46.4 ms ] threadA turn off from what, exactly? IMO it does a great job of quickly setting the context of what you are looking at before describing why you might care:
> It's not production ready at all, but that doesn't mean there is no value in the project. If you ever wanted to read database code without getting overwhelmed by massive amounts of code, dbeel is for you.
Did you finish the entire book then write it, or did you do it chapter by chapter?
The key insight being that in this model "locks are never necessary", which is huge source of efficiency when working with sharded data across multiple cores.
> Thread-per-core architectures are friendly to modern hardware, as their local nature helps the application to take advantage of the fact that processors ship with more and more cores while storage gets faster, with modern NVMe devices having response times in the ballpark of an operating system context switch.
Please do!