I assume it's called this because a cockroach can supposedly survive a nuclear attack. But it's a bad name. It does not invoke good feelings.
CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
11–20 of 57 posts
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#12How would one communicate with this DB? I'd love to see some API examples.
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#13I 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/
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#14Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#15Edit: 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.
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#16Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#17How does it handle replication and the resulting conflicts?
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#18How 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.
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#19Riak, 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…
Of course for people looking at the usage for this, money is not the major issue.
Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#20As for the name, which I agree is problematic as is, how about EntomoDB for entomos (insect)? 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.