8 Reasons You Should Like CouchDB… and not only
While this is not the ☞ original title, I’d say it would summarize pretty well Jilles Van Gurp’s post about the set of features he liked most in CouchDB:
Document oriented and schema less storage
That’s definitely not unique. Here on MyNoSQL, we are aware of at least 4 document databases: CouchDB, MongoDB, Riak and Terrastore.
Conflict resolution
MongoDB encourages a master-slave setup so it will not have to deal with conflict resolution. Terrastore doesn’t have to address this either as the value of a key lives on a specific node and updates will be applied in their chronological order. Riak uses vector clocks for conflict resolution.
Robust incremental replication
Replication is supported by both Riak and MongoDB. Terrastore, being built on top of Terracotta, uses a different strategy:
Terracotta replication is not full, nor geared toward all nodes, but only those actually requiring the replicated data. This is more and more optimized in Terrastore, where, thanks to consistent hashing and partitioning, data is not duplicated at all. Terrastore also guarantees that data will never be duplicated among nodes, unless new nodes are joining or older nodes are leaving, thus requiring data redistribution.
You can read more about Terrastore approach on Terrastore: a consistent, partitioned and elastic document database.
I leave it up to the readers to comment based on their experience how robust replication is in each of the MongoDB, Riak and Terrastore case.
Fault tolerant
The explanation in the original article is more about durability than fault tolerance. In that regards, as far as I know only MongoDB is not really durable.
On Riak case, each write operation can specify the number of virtual nodes involved in the operation and also the number of successful durably writes.
Terrastore is durably storing its data on master whose availability can be enhanced by putting it in active/passive mode (simply put there can be passive masters that would take on the tasks once the initial master has failed).
I should probably mention that in terms of the fault tolerance definition, both Riak and Terrastore are fault tolerant.
RESTful
Both Riak and Terrastore are HTTP friendly.
I left at the end the three reasons that are either more specific to CouchDB implementation or are debatable.
- cleanup by replicating
This sounds more like something specific to CouchDB append only approach.
- incremental map reduce on read
I’m not sure I understand the benefits of this.
- it’s fast
As always, this sort of arguments are highly debatable and it always a good idea to use very well crafted benchmarks that fit your app scenarios.
In conclusion I’d say we ended up with 5 reasons you should like CouchDB and Riak and Terrastore. And I bet a change in the requirements (see as an example: On why I think these pro MongoDB arguments are not unique) would result in any other combinations of these four NoSQL solutions.
Special thanks to Sergio Bossa for clarifying some aspects related to Terrastore.
