MongoDB as a NoSQL, when to use or not

Here is a great stackoverflow about when to use MongoDb versus RDBMS

http://stackoverflow.com/questions/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems

The most crucial sentence is that:

NoSQL is a great tool, but it’s certainly not going to be your competitive edge, it’s not going to make your app hot, and most of all, your users won’t give a shit about any of this.

After that killing sentence :), lets go with some advantage and disadvantage of NoSQL, specifically MongoDB

Advantages:

Document oriented and schemaless

This is the most prominent advantage of using NoSQL databases. They are good to store unstructured data, 

Unlike relational DBs, MongoDB stores all your data in collections of BSON documents and has no schema

It worths for rapid software development where you basically can’t afford to spend too much time doing schema design

Horizontal Scalability and High Availability

 

MongoDB allows to build a clustered topology with replication and sharding, where the former provides fail-over and eventually consistent read scaling and the latter facilitates scaling out writes(and reads as well).

Just add up nodes and it can scale horizontally quite well.

Fast writes in the fire-and-forget mode. Which is quite useful for collecting various statistics where possible loss of some data is acceptable in favor of a shorter response time.

It’s Free and OpenSource. 

Disadvantages:

No SQL = No Joins.

You end up writing jobs to do things like joining data from different tables/collections, something that an RDBMS would do for you automatically.

MongoDb queries can retrieve data from only one collection and take advantage of only one index.  n many scenarios, this means more round-trips to the server to find related records. And then you start de-normalizing data - which means background jobs.

No foreign key constraint to ensure data consistency

MongoDB does not support transactions, so it is not suitable where it is needed. You can imagine money transfer or other complex operations.

Well suited for the following situations

• Scaling out
• Caching
• High volume traffic

Less suited for the following situations

• High transactional  applications
• Ad-hoc business intelligence
• Problems which require a sql solution

In Summary

• Need fast? consider
  Need horizontal scaling? consider
  Need fast programmability / agile? consider
  Need some atomicity? consider
  Need complex transactional semantics? no
  Need SQL? no
  Lots of reporting? a little reporting: fine. real time stats: great. lots of traditional reports: SQL GROUP BY is very powerful. but see also scale.

Ref:
http://blog.iprofs.nl/2011/11/25/is-mongodb-a-good-alternative-to-rdbms-databases-like-oracle-and-mysql/
http://stackoverflow.com/questions/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
http://ethangunderson.com/blog/two-reasons-to-not-use-mongodb/
http://nosql.mypopescu.com/post/703837964/when-should-i-use-mongodb
http://ilya40umov.wordpress.com/2013/03/05/considerations-for-choosing-or-not-choosing-mongodb/
http://ryanangilly.com/post/1091884265/3-reasons-to-use-mongodb