How to choose a NoSQL Database

NoSQL has been beautifully explained by Martin Fowler in his book especially the four main types of NoSQL databases.

1. KeyValue Databases e.g Riak, Redis, Berkeley DB, CouchBase etc.
2. Document Databases e.g MongoDB, CounchDB, OrientDB etc.
3. Column Family Databases e.g Cassandra, HBase, Amazon DynamoDB etc.
4. Graph Databases e.g Neo4J, OrientDB etc.

Note: OrientDB is a multi-model database hence is both a Document and Graph Database. ArrangoDB is another such example. Quite unique and useful in many ways.

One must be well familiar with each type so that one knows “how to choose a NoSQL tech”. However, it seems to be more appropriate to point out “How *NOT* to choose a NoSQL store”.

1. Cool Factor: To replace your existing SQL database because it’s simply “cool”. Since NoSQL is not a silver bullet one should choose a tech just because its in fashion.
2. Less Data/Scale: You may under utilize or put more efforts just to accommodate few hundreds/thousands of records in NoSQL data store. This may be easily managed in efficiently and cheaply in any SQL Store and modern ORM suites make it very easy to manage it. Everything looks like a nail when you have NoSQL hammer. BigData technology you use is very specific to your use case. Have seen cases where even Elasticsearch has been used like a schema-less data store. (Yes, it can be!)
3. Application Architecture: You application architecture is more like a on-premise application deployed to cloud and does use a true blue micro-service/cloud architecture with features like scaling, auto-discovery, load balancing, fault-tolerance etc. In such case you may not really reap benefits of scale or cloud may prove a costly affair you.
4. Schemaless: When you are not planning to use full advantage of schemaless database. i.e You use NoSQL database just like a SQL store. Where your applications’ data model object / ORM objects are tightly coupled with the schema. i.e a schema change breaks your code “everytime”. This also requires you to deal with all SQL like processes for database migrations and upgrades when your business logic changes. Although cannot be completely avoided at times there is no reason why your application should break “everytime” you add a new attribute to NoSQL data store.
5. SQL Interface: You are choosing a NoSQL database just because it provides a familiar SQL or SQL like interface e.g Cassandra.
6. Consistency: Most NoSQL database are eventually consistent and not ACID but if your system requires strict transactions then you may need to think again.

Although these are just general thoughts and not a strict guideline.

Let me know what your thoughts about choosing a NoSQL datastore.