What is it?
MongoDB (NoSQL) supports changing the structure of records, called documents in this case, simply by adding or deleting existing fields. This gives the ability to represent hierarchical relationships, to store arrays and different complex structures with ease. Documents in a collection need not have an identical set of fields and de-normalization of data is common. MongoDB was also designed with high availability and scalability and includes out-of-the-box replication and auto-sharding. Companies like MTV and Cisco have already adapted the use of relational databases to MongoDB. MongoDB supports rich data model as compared to MySql. It removes complex transaction and makes it easier for programmers to handle dynamic schema.
A brief comparison:
MySQL Table Row Column Joins MongoDB Collection Document Field Embedded documents, linking People are seeing real world MongoDB performance mainly because it allows you to query in a different manner that is more sensible to your workload. Why or Why not. MongoDB cannot be directly termed as drastically faster. If you store the same data, organized in basically the same format, and access it exactly with the same method, then the result wouldn’t be magically different. Both MySQL and MongoDB are GPL (General Public License), so MySQL team could just have incorporated it into their codebase if MongoDB had some better IO code in it.
Consider a design that is a structure with a lot of information about a complicated entity in a normalized form. MySQL (or any relational DB) could easily use dozens of tables to store the data in the normal form, with numerous indexes to guarantee relational integrity between tables.
If the same design is considered with a document store technique and says all of those related tables are subordinate to the main table, then you might be able to achieve a data model such that the entire entity is stored in a single document. MongoDB allows storing this as a single document, in a single accumulated collection. This is where MongoDB results in a superior performance than the latter. Refer https://www.mongodb.com for more information.
In order to retrieve a whole entity in MongoDB, single index lookup on the collection (documents) and retrieve the contents of one database page which is the actual binary JSON document. Whereas in MySQL with (say) 20 tables, you have to perform, one index lookup on the root table and with a clustered index, assuming that the values for the root row are somewhere in the index. 20 above range lookups will usually be performed. So the total for MySql, even assuming that all indexes are in memory will approximate to 20 range lookups. These lookups are likely comprised of random IO, different tables will definitely reside in different spaces on disk, and it’s possible that different rows in the same range of the same table for an entity might not be contiguous if updated or altered in any case. So the final tally is about 20 times more IO with MySQL per logical access through lookups, compared to MongoDB.
With the help, MongoDB, building applications that were never possible with traditional relational databases seems to take a step further into improvement.