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.
Actually this all does remind me of research on the tangible effect of disgust on products -- see [0]. That work studied physical contact, but it's easy to extrapolate from there.
[0] https://faculty.fuqua.duke.edu/~gavan/bio/GJF_articles/conta...
It was a database for counting the clicks on our website :-)
Financial transactions are pretty much the poster child for atomic, multi update transactions and pessimistic locking.
You're right that it's different from, say, master/slave replication in an SQL database. There's no distinction between an authoritative master and a slave that provides stale data. Each machine either gives you consistent reads and writes, or is unavailable.
As far as latency goes, the gory details are in the design document. You need to talk to at least N/2 other replicas; there's no way around that without giving up consistency. But that doesn't mean you can only do one transaction every 50ms; they can be pipelined, and non-conflicting transactions can proceed simultaneously.
>I would consider that "proper" replication in the sense of a replicated state machine.
When I think about proper replication, I'm thinking about master-master replication which doesn't fail if the connection between peers is sometimes down, even for very long periods (e.g. what CouchDB can handle). I'm of course not saying that other kinds of replications are somehow inherently bad, but multi-master replication without active connections is what I'm after and what a lot of modern applications can benefit from.
Once you have two databases that are not connected all the time you need to handle conflicts. You can move the conflict handling totally to the client side, but the conflict handling must be implemented somewhere. I think that's such a common use-case that the database should provide basic interfaces and implementation for it. If nothing else, it reduces boilerplate code by large amounts. Of course no database can handle conflict handling fully, as some of it always depends on the business domain.
It is not the transaction itself that is hard, it is the network partition. E.g. what happens if two network partition approve transactions, that wouldn't have been accepted if there were no partitions.
If this DB is the sole record of The Money, and I can move some quantity from X to Y in a transaction, then that's fine by me.