MONGODB When to go for MongoDB ~ GNIITHELP

When to go for MongoDB

First and foremost, MongoDB is not a replacement for any traditional RDMS databases. But, considering the fact that the MongoDB structures/stores the data in the form of BSON (Binary representation of JSON) which is a self-explaining and human readable data format and the way it provides the scaling feature to the application to be developed, below are some important factors which clearly states that the developer(s) should go for the use of MongoDB for developing their applications.

---

Data Insert Consistency

Basically, MongoDB likes to have more data insertion rate over the safety concerns of doing inserts in a transaction. Hence the write consistency is low. If there is a need for huge load of data to be written, without the worry of losing some data, then MongoDB should be preferred and really it's best suited.

Data Corruption Recovery

When data recovery process needs to be faster, safe and automatic, MongoDB is preferred. In MySQL if a database (a few tables) become corrupt, you can repair them individually by deleting/updating the data. In MongoDB, you have to repair on a database level. But there is a command to do this automatically, but it reads all the data and re-writes it to a new set of files. So if your database is huge, it might take some time, and for that time your DB will be locked. But again, this is better than losing the complete dataset.

Load Balancing

When data grows infinitely and proper load balancing of the same is required, MongoDB is the best solution. Because, it supports, faster replica setting options and its built in Sharding feature.

Avoid JOINS

When the developers do not want to normalize their data and insist on not using of any JOINS, then they should really go for MongoDB. For Example : If there are 2 collections student and address (where a student can have more than one address). In a typical RDBMS, to fetch the addresses associated to a student from the address table, JOIN is used. But, in MongoDB, the address data can be embedded as a document in the student collection itself. Hence, without using any JOIN all the required details of student and address can be fetched with one simple query.

db.address.insert([
    {
        _id: 'addr1',
        name: 'Bangalore'
    },
    {
        _id: 'addr2',
        name: 'Delhi'
    }
]);

db.student.insert([
    {
        _id: 's1',
        name: 'Student1',
        address: ['addr1']
    },
    {
        _id: 's2',
        name: 'Student2',
        address: ['addr1','addr2']
    },
]);

Best suited for changing schema

It is a known fact that, whenever a table in any RDBMS is altered (like adding a new column), there is a high chance that the entire database might get locked which in turn result in a big performance degradation. Since, MongoDB is schema-less, hence adding new fields will not result in any issues.

Not Relational data

When the data to be stored need not to be a relational one, then MongoDB should be selected.

Some more reasons...

1. Even though SQL databases possess very good consistency, they are bad in partitioning of the data. NoSQL database like MongoDB can be used in this scenario.
2. Mapping of your application Data objects, directly into the document based storage is very easy. As the JSON like format closely resembles the Object representation in any programming language. Document matches more closely to an object than a set of relational tables of RDBMS.
3. If you plan on creating a DB cluster, which might be geographically distributed to provide speeded up data queries, then MongoDB should be your choice.