When to go for MongoDB

Welcome to a tutorial on MongoDB. Here you learn why and when to go for MongoDB.

You should know that MongoDB is not a replacement for any traditional RDMS databases. However, MongoDB structures/stores the data in the form of BSON (Binary representation of JSON) which happens to be a self-explaining and human-readable data format as well as a way it provides the scaling feature to the application to be developed.

Data Insert Consistency

MongoDB employs more data insertion rate over the safety concerns of doing inserts in a transaction. Therefore, the write consistency is low. In a situation where there is a need for a huge load of data to be written, without considering the loss of data, hence, the preferred Database to use is MongoDB.

Data Corruption Recovery

In this case, if the recovery process of data needs to be faster, safe, and automatic, then we can use MongoDB.

In MySQL, if a database or a few tables become corrupt, one can repair them individually by simply deleting/updating the data. But, in MongoDB, all you need to do is to repair on a database level, interestingly, there is a command to do this automatically, although it reads all the data and re-writes it to a new set of files. Therefore, if we have a huge database, it might take some time, and during that time your Database will be locked. But, it is preferable to lose your dataset completely. 

Load Balancing

MongoDB is the best option when data grows infinitely and proper load balancing of the same is required. This is because it supports faster replica setting options and its built-in Sharding feature.

Avoid JOINS

Now, if a developer does not want to normalize its data and insists on not using any JOINS, then he should go for MongoDB. Take for instance, if there are 2 collections of students and addresses (that is a case where a student can have more than one address). Hence, in a typical RDBMS, to fetch the addresses associated with a student from the address table, JOIN is used. However, in MongoDB, the address data can be embedded as a document in the student collection itself. Therefore, without making use of any JOIN all the required details of the student and address can be fetched with one just a query.

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

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

Best suited for changing the schema

It is commonly known that if a table in any RDBMS is altered (like adding a new column or row), there is a high possibility that the entire database might get locked which in turn results in big performance degradation. But with MongoDB which is schema-less, adding new fields will not result in any problem.

Not Relational data

In a situation where the data to be stored does not need to be a relational one, then MongoDB should be selected.

Additional reasons

• Although SQL databases possess very good consistency, they are bad in the partitioning of the data, while NoSQL databases such as MongoDB can be used in this situation.
• The Mapping of application Data objects directly into the document-based storage is very easy. This is because the JSON-like format closely resembles the Object representation in any programming language. Also, a Document matches very closely to an object than a set of relational tables of RDBMS.
• In the case any developer plan on creating a DB cluster, that might be geographically distributed to provide speeded-up data queries, then the preferred DB should be MongoDB