6 ms·
From the blog: > Because gun is not a database (NoDB), it is a persisted distributed cache. This I believe. > The fatal flaw with databases is that they assu
by barakm 12y ago
From the blog:
> Because gun is not a database (NoDB), it is a persisted distributed cache.
This I believe.
> 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.
Partially true. Though that's not necessarily a "fatal flaw", and calling it such is troubling. Yes, concurrency is unavoidable when you become large enough but you also want your data to be, well, consistent and persistent, but then you go on...
> 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.
Where in the code, pray tell, is it solving these problems? The fact that you also claim to be an AP system (and conflate this with ACID) makes me strongly wonder what your notions on Consistency actually are.
"Just a cache" needs some consistency as well, I'll point out, but you may not care as much about stale reads.
> It gets data synchronization and conflict resolution right from the beginning, so it never has to rely on vulnerable leader election or consensus locking.
From what I'm starting to understand you're, at best, shuffling that off to S3 or "other storage engines" -- you've still got to pay the cost. You can't really claim to do linearizability without, well, actually doing linearizability.
So, maybe it's a cache, sure. And you seem to like to work on the developer API, nothing wrong there. But there's nothing new under the sun and I'm really skeptical that hard distributed database problems are solved in one large JS file.
- stephanfroede 12y agoWhat are "hard distributed database problems"? I came to the conclusion that they do exist, but I have observed a need to manage millions of tiny write transactions per second-> IoT.
- marknadal 12y agoI've come to a similar conclusion. The smaller your updates are the better, and allow for cleaner data sync. Check out my other reply.
- marknadal 12y agoClarification, I said GUN is NOT acid compliant from your "usual" understanding of the term, since GUN is AP. Most people assume acid means CP. ACID is very vague though, and I'd like to explore it more by writing tests to either confirm or deny whether GUN supports it or not (would you be interested in helping build those tests?). I also want to get some Jepsen like tests up as well. Data convergence (data sync) is guaranteed by the Hypothetical Amnesia Machine algorithm, which is completely deterministic and idempotent. There is some details on it in the wiki, let me know if you have any questions. I also did a tech talk on it. In NO way does gun rely on S3 for consistency. That would be horrible. Check out the algorithm and slam me with questions/critiques. Thanks for looking. :)
- theseoafs 12y agoYou do not prove a system is ACID by writing and running test cases. Does the team behind this have experience with distributed systems?
- marknadal 12y agoYes, I've spent the last 4 years doing consulting work and research on them. Warning: I have a very different approach though, more on the side of bittorrent and bitcoin, than what you are going to find in your traditional databases (CP, Master-Slave, Consensus/PAXOS/etc.). If you are a distributed systems person also, I'd really like to talk. If you're armchair/backseat scoffing, then I would still love to talk show you how the algorithms work.
- theseoafs 12y agoSorry if you were offended by my question; I didn't intend any disrespect, but I hope you'll forgive me if I say that this HN submission is very confusing. The webpage claims that Gun is both the "easiest database ever" and "not a database" (interesting, then, that the website's URL is gundb). It claims that the problem with databases is that they assume there's a "centralized authority", which is sort of absurd; the overwhelming majority of businesses and organizations that use databases have at least some data that they need to absolutely 100% guarantee is safe and consistent, and distributed algorithms with leaders are the easiest way to capture that. Also, what is "vulnerable" about consensus algorithms? Does your distributed database really have no way to reach consensus? Persistence is solved with "any S3 like service"? So what does that mean, using Gun is going to tie me to another unrelated Database as a Service that I'm going to have to pay Amazon for? I'm sure this tool offers something interesting that other tools can't match, since you made it and put time into it, but the existing documentation isn't capturing that yet. Write up another blog post that describes the details, the use cases, the guarantees, etc.; i.e. the actual hard technical details, rather than the PR-speak, and I'll happily take a second look.