Hacker News new | past | comments | ask | show | jobs | submit login

To be a tad more concrete: GunDB can run in the browser as well as on servers; CockroachDB is a traditional, client/server database. GunDB is aiming for eventual consistency, but when I looked a year ago, it seemed like the algorithm they chose wasn't actually convergent--nodes could diverge because non-commutative updates could be applied in different orders on different nodes. CockroachDB, by contrast, is a serializable, single-key linearizable store. I don't think GunDB offers transparent sharding or SQL, both of which are important aspects of CockroachDB.

Both depend on wall clocks.




Aphyr, thanks! I appreciate seeing you here and replying. GUN Author here.

First, to answer @sroussey - Kyle is correct, GUN is an eventually consistent graph database that runs browser/server with extremely high availability, while CockroachDB is trying to be a strongly consistent, linearizable key/value SQL store. To read about what we guarantee/don't, check out these articles:

https://github.com/amark/gun/wiki/CAP-Theorem

http://gun.js.org/distributed/matters.html (tech talk on how the algorithms work)

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

The last year we've focused on performance, and can now do 25M+ reads/sec (no cache miss, disk I/O performance isn't particularly interesting to us). More on that here: https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2... (we're not kidding about it being able to run in the browser)

With regards to commutative / non-commutative, @Aphyr, slight correction: Different machines will converge to the same value, it is just that you'd need to use a commutative CRDT on top of gun (we have one here: https://github.com/amark/gun/wiki/snippets-(v0.3.x)#counter ) for them to converge to their combined value.

Example: GUN treats primitives as atomic, so if you try to `gun.get('some').path('math').put(5 + 2)` it will converge to the atomic value of 7. So if two machines do `gun.get('some').path('math').put(currentValue + 2)` at the same time, both machines will converge to the fixed atomic value, not a commutative value - you need the CRDT for that.

I mention this in the "What could go wrong?" section of the talk (linked above), and it is easy to add the necessary CRDT when you need it - actually, this was inspired by you @aphyr, from our discussion a few years ago.

Note: @Aphyr, we built a distributed testing framework ( https://github.com/gundb/panic-server ), and now that our "performance improvement" stage is done, in the near future we're going to start building distributed correctness tests (we're rolling out to a government client soon). We'll probably be in touch with you in the next half year or so. :)

Great work, keep it up. You are always a huge inspiration. <3

Edit: With regards to sharding / SQL, we don't have SQL support yet but somebody is currently building a prototype for it. Sharding, not built in, but peers store the data they request, which acts as a natural shard, but nothing fancy - for more info check out this article: https://github.com/amark/gun/wiki/sharding .




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: