A short useful read specific to database selection: How to choose a NoSQL Database?. I will highlight keypoints in this answer.
Key-Value vs Document-oriented
Key-value stores
If you have clear data structure defined such that all the data would have exactly one key, go for a key-value store. It’s like you have a big Hashtable, and people mostly use it for Cache stores or clearly key based data. However, things start going a little nasty when you need query the same data on basis of multiple keys!
Some key value stores are: memcached, Redis, Aerospike.
Two important things about designing your data model around key-value store are:
- You need to know all use cases in advance and you could not change the query-able fields in your data without a redesign.
- Remember, if you are going to maintain multiple keys around same data in a key-value store, updates to multiple tables/buckets/collection/whatever are NOT atomic. You need to deal with this yourself.
Document-oriented
If you are just moving away from RDBMS and want to keep your data in as object way and as close to table-like structure as possible, document-structure is the way to go! Particularly useful when you are creating an app and don’t want to deal with RDBMS table design early-on (in prototyping stage) and your schema could change drastically over time. However note:
- Secondary indexes may not perform as well.
- Transactions are not available.
Popular document-oriented databases are: MongoDB, Couchbase.
Comparing Key-value NoSQL databases
memcached
- In-memory cache
- No persistence
- TTL supported
- client-side clustering only (client stores value at multiple nodes). Horizontally scalable through client.
- Not good for large-size values/documents
Redis
- In-memory cache
- Disk supported – backup and rebuild from disk
- TTL supported
- Super-fast (see benchmarks)
- Data structure support in addition to key-value
- Clustering support not mature enough yet. Vertically scalable (see Redis Cluster specification)
- Horizontal scaling could be tricky.
- Supports Secondary indexes
Aerospike
- Both in-memory & on-disk
- Extremely fast (could support >1 Million TPS on a single node)
- Horizontally scalable. Server side clustering. Sharded & replicated data
- Automatic failovers
- Supports Secondary indexes
- CAS (safe read-modify-write) operations, TTL support
- Enterprise class
Comparing document-oriented NoSQL databases
MongoDB
- Fast
- Mature & stable – feature rich
- Supports failovers
- Horizontally scalable reads – read from replica/secondary
- Writes not scalable horizontally unless you use mongo shards
- Supports advanced querying
- Supports multiple secondary indexes
- Shards architecture becomes tricky, not scalable beyond a point where you need secondary indexes. Elementary shard deployment need 9 nodes at minimum.
- Document-level locks are a problem if you have a very high write-rate
Couchbase Server
- Fast
- Sharded cluster instead of master-slave of mongodb
- Hot failover support
- Horizontally scalable
- Supports secondary indexes through views
- Learning curve bigger than MongoDB
- Claims to be faster
