Advantages and Disadvantages of MongoDB

Posted By : Lokesh Kumar | 29-Mar-2018

mongodb

MongoDB is generally new player in the information storage circle when contrast with the monster like Oracle. However, it has drawn a considerable measure consideration with a disseminated key-value store, fit for MapReduce figuring and document-oriented NoSQL highlights.

The logic behind MongoDB is to hold however many functionalities as would be prudent while allowing horizontal scale and in the meantime, to make designer's lifeless demanding. It sits between the effective however wasteful relational database and elite yet straightforward key-value store framework.

MongoDB possibly cool, however before you settle on the choice, it's significant to think about whether is the correct database for your application. That is, think about what it can do, what it can not, the focal points and inconveniences. Nothing is more agonizing than you construct your entire application on a database model and later discover they don't fit together.

MongoDB possibly cool, however before you settle on the choice, it's significant to think about whether is the correct database for your application. That is, think about what it can do, what it can not, the focal points and inconveniences. Nothing is more agonizing than you construct your entire application on a database model and later discover they don't fit together.

This post discusses the upsides and downsides of MongoDB from different angles. How about we begin with the performance.

1.) Performance advantages:-

MongoDB is a database which intended for enormous information storage and inquiry, goes for Social Network applications like Facebook. MongoDB picks up its performance for the most part by key-value based plan and simple to scale out. Being one of the NoSQL databases, MongoDB utilizes document as the essential storage unit.

A document is only a basic JSON like object, called BSON in MongoDB, which is only a blob. For instance, a blog entry comprises of title, substance, and remarks. In a relational model, the remark will be put away as an individual table and recovered by joining post table and remark table. In document model, they are spared as one document. They are dealt with as a solitary object. While querying, you get everything from that one document, no reference to different documents, that one document can be recognized by an id. Along these lines get a document is a key value query, not a relational query. Key value query is significantly speedier than the relational query.
If you have worked with the relational database before, you may hear the name "denormalization". It's a process that aggregate data from different tables into one table to avoid join operations.

In the event that you have worked with relational database previously, you may hear the name "denormalization". It's a procedure that total information from various tables into one table to stay away from join activities.

Database designers once in a while denormalize database structure deliberately to pick up performance. That precisely what MongoDB document is doing.

The next advantage of MongoDB is scalability. That is, to incorporate more machines as the data and development create and keep the responsive speed and openness.

MongoDB bolsters auto-sharding and auto-failover, so you can center around your business rationale. At the point when the information on one node surpasses limit, MongoDB naturally modifies the information to equitably disseminated node. From the point of view of your application code, a group feels simply like a solitary node. It acts like a transparent, versatile layer of information storage.

2.) The document model:-

A document has no understanding of tables, columns, SQL, schemas, even a few questions are much like the relational database.

For instance, the site movement details, promote clicking stats, etc. Information like this has immense size and feebly related to each other, they don't require 100% consistency, MongoDB is great at putting away and preparing information like this. As a matter of fact, MongoDB was produced in DoubleClick which tracks online promote exercises, now procured by Google to serve its Adsense distributer organize.

A pattern is made on the fly, when you utilize it, it's made. Essentially, you can add any sort of field to MongoDB gathering whenever.

3.) Flexible Schema:-

As a matter of fact, there is no schema in MongoDB, the document can have any number of fields, the fields can be added to existing document at whenever, progressively. No ALTER TABLE, no modify ordering.

The documents are much the same as Javascript JSON, PHP arrays, Clojure maps or Python dictionaries, its exceptionally regular to speak with MongoDB with dynamic dialects like JavaScript, PHP, or Python.

MongoDB is fit for speaking to rich information model with BSON information design, much the same as strict schema database like MySQL.

Now time for talking about the disadvantages of MongoDB.

1.) Not support transaction
To accomplish the performance and scalability, MongoDB trench the exchange bolster. This makes MongoDB simple to scale horizontally which use numerous shoddy equipment to adjust the heap. Scale horizontally is by and large a hard assignment in the relational database like MySQL. However, its a breeze in NoSQL database like MongoDB.

MongoDB is the best fit on the off chance that you have a considerable measure of information, however, the connection between them is powerless, for instance, a surge of autonomous occasions, really the early use of MongoDB is to record online advertisements clicking statistical data. It's not fit for solid related information like your financial balance data, at whatever point you exchange cash, numerous related bank information should be altered in the meantime, and they either all done, or nothing is finished. RDBMS do this by an exchange.

To conquer this, MongoDB bolsters nuclear activities like nuclear addition and decrement, findAndModify. Notice that in MongoDB, just change to the single document is nuclear, yet activities that include various documents are not nuclear. So the best practice is you should store however much as could reasonably be expected data in the single document, abstain from spreading information over various documents, in RDBMS this procedure called denormalization.

Again this restrains the zones that MongoDB can be utilized, on the off chance that you require a gigantic of denormalization to reshape the information model, it's a notice sign, you might be in an ideal situation remain in RDBMS and discover another approach to pick up scalability.

2.) Not support join operation
Since the document contains all that you require, so there is no join. This is likewise the exchange of keeping in mind the end goal to have the capacity to effortlessly scale horizontally. However, you can simply play out your join by making numerous queries.

3.) RAM limitation

MongoDB utilizes memory mapped record, let the Operating System handle the storing. The span of you database is restricted by virtual memory gave by Operating System and equipment.

On the 32bit machine, you can just spare as much as 4 GB information on the grounds that the system can just address 4GB of memory and the OS will use no less than 2GB of space, leaving 2GB for MongoDB mapped records. You can't do much for genuine application with 2GB space. For generation condition, a 64bits system is an unquestionable requirement.

On the off chance that you are playing it on you claim 32bit machine, don't spare genuine information into MongoDB. At the point when the information surpasses the limit, your inclusions may fall flat with no notices!

Conclusion
MongoDB does not have a few highlights of the relational database like the exchange or join, yet it picks up the capacity to scale horizontally effectively and adaptable schema that simple to control with JSON like information design.