Hacker News Re-Imagined

ToyDB: Distributed SQL Database in Rust

59 minutes ago

Created a post β€’ 68 points @adamnemecek

ToyDB: Distributed SQL Database in Rust

@z3t4 β€’ 20 minutes

Replying to @adamnemecek πŸŽ™

So do the throughput decrease when you add more nodes? Or am I reading it wrong? This is a general problem with scaling horizontally, that the overhead can kill the performance, and single core/node performance is sacrificed.

Reply


@void_mint β€’ 15 minutes

https://github.com/erikgrinaker/toydb/blob/master/docs/refer...

This is exactly what I was hoping to find. This is great!

Reply


@mathgladiator β€’ 29 minutes

Well done, I'm excited about efforts like this and I hope you make progress towards some production traffic (I'm aware it is a toy, but toys are best when used by others :) )

Reply


@adamnemecek β€’ 59 seconds

I've been building a prototype of a relational in-memory database in Rust to replace some involved ad-hoc data structures and in the process, I came across this.

I think that all the state management problems and solutions in all languages/frameworks (react, swiftui, elm etc etc) would be better implemented as a database with changefeeds/change data capture [0].

The advantage compared with something like Redux is that it's more general. You don't need to implement an enum with a case for each action and then have a big dispatcher.

All your update logic would be a big switch statement on change feed from the database which would handle all the logic.

The fundamental problem of state management is as follows, if a leaf view changes some data, how some view higher in the hierarchy learn about this?

I think that this solves the problem better than alternatives or the observer pattern.

Ideally the API would be something like LINQ methods in order to avoid parsing SQL.

I'm still trying to figure out if this would work.

[0] https://rethinkdb.com/docs/changefeeds/ruby/

Reply


About Us

site design / logo Β© 2021 Box Piper