Hacker News new | ask | show | jobs
by rubiquity 3941 days ago
> Because gun is not a database (NoDB), it is a persisted distributed cache. The fatal flaw with databases is that they assume some centralized authority. While this may be the case initially when you are small, it always ceases to be true when you become large enough that concurrency is unavoidable. No amount of leader election and consensus algorithms can patch this without facing an unjustified amount of complexity. Gun resolves all this by biting the bullet - it solves the hard problems first, not last. It gets data synchronization and conflict resolution right from the beginning, so it never has to rely on vulnerable leader election or consensus locking.

That's some of the most hand-wavy drivel I've ever read.

2 comments

I don't see what's hand-wavy about it. He makes a clear and succinct point: In a distributed database, managing consistency at scale gets complex because most systems are designed to assume a centralized authority [of consistency]. By removing the centralized authority and making conflict resolution the main mode of operation, the design can (according to the author) be made simpler.

I don't disagree with any of that, and it's not a new idea (Lotus Notes and CouchDB come to mind as databases that solve replication through conflict handling), although I'm not seeing a clear description of how this synchronization algorithm actually works. There's a description in the wiki [1], but it's unfinished. (Looking at the code, the entire project looks like quick-and-dirty, unfinished prototype, actually.)

[1] https://github.com/amark/gun/wiki/Conflict-Resolution-with-G...

Consenus, replication and consistency are potential solutions and their own problems to another entire set of really hard problems. If you're going to say you solved them you better say how, and most importantly, what tradeoffs you made to do so.
Good point, I'm definitely lacking coverage on my documentation. But we're working on it.

GUN is a AP system, so you do not get Strong (Global) Consistency, instead it is Eventually Consistent and Highly Available. For more information on this, check out the wiki: https://github.com/amark/gun/wiki/CAP-Theorem .

Basically you do NOT get linearizability for free, you have to build that ontop where it is baked explicitly into the data, with a CRDT or DAG or something. In the future, there should be extensions for this so you don't have to worry about it.

I'd love to see Kyle Kingsbury put that through it's paces.
Me too! I'm lucky enough to be talking alongside Kyle at https://2015.distributed-matters.org/ber/ in a few weeks. I'm hoping to get to know him and see if he'll bash up my database and help find flaws (I'm very confident in the mathematics of the system, however implementations are far from academic).