Change the name. I get the joke, but it has an emotionally negative connotation that bosses will hate.
CoachDB ?
CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
31–40 of 57 posts
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#32Earlier quoted context omitted.
Fully ACID transactions is a big deal.
Riak will have strongly consistent buckets in 2.0+, which pretty much takes care of the cases in which I'd need guarantees for data in this storage model.
Consistency of single updates is vastly different than multi-write atomic transactions. The former precludes, for example, financial applications which require atomic updates of multiple balances.
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#33Earlier quoted context omitted.
Trademark considerations aside, I'd vote for TwinkieDB
Or even better, TwinkDB.
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#34Change the name. I get the joke, but it has an emotionally negative connotation that bosses will hate.
CroachDB
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#35Change the name. I get the joke, but it has an emotionally negative connotation that bosses will hate.
Agreed. Take out the 'roach' part and watch its popularity skyrocket.
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#36Earlier quoted context omitted.
Fully ACID transactions is a big deal.
They're based on Raft--that's not a consensus protocol that's designed for multi-datacenter operations. I suspect you'll have reliability and throughput issues fairly quickly, just as you see with multi-datacenter zookeeper. 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…
[deleted]
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#37Change the name. I get the joke, but it has an emotionally negative connotation that bosses will hate.
+1
Terrible name.
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#38That's a funny name for a database. At least you'll know that whoever uses it does not use it for its buzzword value. 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 s…
Cockroaches are resilient and hard to kill.
I'm aware of that.
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#39Riak, when you use LevelDB behind it, certainly has indexes. As many as you want (within reason), through secondary indexes[0]. While it doesn't have joins specifically, you can link data blobs and walk the links[1]. For when that isn't quite enough, you can always perform a compiled erlang map reduce across a given dataset[2]. I don't quite see how CockroachDB offers anything Riak doesn't. Riak, while not offering t…
Simple, CockroachDB is a CP system, while Riak is an AP system.
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.