How will this handle partitioning of the network? The readme has a lot of info about bits of the far-flung cluster failing but nothing about how it would deal with the whole cluster being chopped up into roughly equal halves. That's one of the harder problems to deal with for solutions aimed at this space.
I don't quite see how CockroachDB offers anything Riak doesn't.
Riak, while not offering true locking transactions (it doesn't look like CockroachDB does either - imagine how long it would take to perform a locked transaction across sixteen data centers in as many countries, two of which have gone dark due to power outages and giant robots), offers you the option of resolving data version conflicts when you read the record[3]. (ed. Many times if doing a partial update of a record, you need to read before writing anyway. This resolves a conflict before you write to a potentially conflicted record chain. Typically this is done with a pre-commit hook. [4])
(ed.: The major differences seem to stem from the snapshotting system CDB uses to provide external consistency across data centers. This comes at a (potentially huge, especially if two clusters lose connection with each other but not with clients) delay in write verification.
Riak, on the other hand, would still allow writes - and would resolve any conflicts when the datacenters connect again. It's a hairy problem to fix, especially in a general manner.
It all depends on what kind of data you're storing.)
0. http://docs.basho.com/riak/latest/dev/using/2i/
1. http://docs.basho.com/riak/latest/dev/using/link-walking/
2. http://docs.basho.com/riak/latest/dev/using/mapreduce/
3. http://docs.basho.com/riak/latest/theory/concepts/Vector-Clo...
4. http://docs.basho.com/riak/latest/dev/using/commit-hooks/
If you need multi-key ACID transactions, and can tolerate potential downtime in the event that some partition loses a majority of its Raft replicas, you might want to use CockroachDB.
If high availability is a concern, and you can tolerate the occasional data conflict in the case of incomparable vector clocks due to writes accepted during a network partition, or, if your schema can be modeled with CRDTs (LWW register, PN counter, Union-Set, etc), you might want to use Riak.
Of course for people looking at the usage for this, money is not the major issue.
Is that referring to Riak's cross data center replication (enterprise feature). I guess for regular case (non-enterprise version) it is true, as it is not possible to specifically assign ring sections to data centers?
The solution Google uses for this kind of problem: multidatacenter transactions are rare, so they're not optimized for latency (instead for reliability), and they tend to use 2PC, as it's easier to get right with unpredictable WAN latencies.
Terrible name.
1. https://twitter.com/andybons/status/472458545154494465. The answer to that question, btw, is yes. Reposts of stories that have had significant attention are treated as dupes for about a year.
2. That's not a criticism of the submitter. We want to see original work on HN. But there ought to be some substance to it, as well as to the resulting discussion.
I'd love to see some API examples.
And an RDBMS-like layer on top of it: http://godoc.org/github.com/cockroachdb/cockroach/structured
Edit: It's not problematic if success is not an objective. But if it is, choosing a name with such strong established negative connotations is not wise.
Most people are disgusted by cockroaches. I think that's a good enough reason to change the name, at least if you want the product to be taken seriously.
