Why CouchDB

Design : Why CouchDB

Why NoSQL

1. Lots of HTML and text data, write-once (may be more than once), read many times.
2. Shard-able, distributed.
3. REST based, JSON based.
4. Want to try!

Why CouchDB

1. MongoDB is strictly consistent. Distributed MongoDB is basically sharded master-slave architecture, so only master is write-through.

2. CouchDB is meant to be distributed, Eventual Consistency is the feature I want to learn and test.

3. CouchDB is replicated, so creating a new box should not be an issue.

   • Replicate filesystem
   • Replication API

Some more thought went into it, because CouchDB, CouchBase (CouchDB+Membase) uses Map-Reduce to perform fetch query. Map-Reduce is not fast, and our databases are write-once, read-many time. So sacrificing read performance is not acceptable. MongoDB apparently uses Map-Reduce to fetch data as well. CouchBase claims at-least an order faster than MongoDB but when deployed on a multi-node cluster, on single node MongoDB outperforms.

These information are not verified, I have no benchmark to prove any of it.

Going to work with CouchDB, because

1. Can’t avoid Map-Reduce
2. Both are b-tree
3. CouchDB is still eventually consistent, and not a master-slave architecture.

@Read Guide to NoSQL