Why are people shifting to MongoDB?

Hey guys, these days you might have seen MongoDB being so much more famous than SQL based databases such as MySQL or PostgreSQL. Even in college courses and interviews, people are switching from asking SQL questions to MongoDB fundamentals. But why is it so? Let's look at some things which make MongoDB a unique, much better and futuristic database in today's time.! P.S I am coming up with a 5 day LIVE course to learn MongoDB and get to understand all important concepts..! Register for it now..!

What's different in MongoDB?

MongoDB is a NoSQL based "document database". This means that it does not follow the Relational RDBMS internals and do not have relationships defined. Instead, it follows a more natural - JSON like structure (BSON data type) as individual records or rows in the database. You can keep all "related" information together in a single document, for example a User document might look like -

{
    "_id": ObjectId("123456677"),
    "username": "shreybatra",
    "name": {
        "first": "Shrey",
        "middle": null,
        "last": "Batra"
    },
    "age": 25,
    "mobileNumber": "999999999",
    "socialLinks": {
        "github": "some_url",
        "linkedin": "some_url"
    },
    "addresses": [
        {
            "house": "123",
            "country": "..."
        },
        {
            // more addresses
            ...
        }
    ]
}        

Over here, I have tried to add all common data types such as string (name), integer (age), nested/embedded data (socialLinks), arrays of data (addresses). Along with this, MongoDB supports much more types of data such as

• ObjectId - An auto-incremental unique identifier used as the "id" of the document.
• Date Time -- You can store an ISO datetime which is very same as python's datetime or JS Date object.
• Floats - You can store floats and decimals and complex values
• And much more...! Check out the BSON specification

What else than data type? How does Document Database help?

Well, it's everything. Coming from a SQL background you may seem confused and find it tough to understand that a Document Database / document world is a different perspective than your SQL world. Where you have normalisation to improve performance and data modelling in SQL world, you have similar data modelling concepts and patterns in MongoDB world but in a quite different perspective.

MongoDB Moto: Data that is accessed together, stays together..!

Just memorise the above thing, that's what the document database world relies on. Instead of breaking and normalising your data, you keep your data together in a single object (preferably) so that whenever you need to read the data, you have exactly 1 place to read, with minimal joins and extra lookups.

Does that mean that you should always club all information together in a Single Document?

No..! Absolutely not...! If you think MongoDB does not support Joins then you are absolutely wrong. It's a very important feature and when we say embed data than normalise, you might wanna read the quote again..!

Data that is accessed together, stays together..!

Now, imagine a system having Inventory, Users, Product Orders. You can't club the Orders data in Inventory, as a single document having all details of object as well as all transactions. You can't club all orders inside a User object saying all orders from the User stays in the User object (or document). That will simply not scale. You will have to break it down into 3 different Collections (or tables in SQL world) and join them as and when needed.

Does this mean we have a performance hit when compared to SQL world?

Absolutely not..! Looking at data from a different perspective does not mean it has a worse performance than SQL database. Instead, in many scenarios it would be even better than a SQL database, specially in terms of Developer Productivity and efforts needed to scale a MongoDB database (shard / partition / etc.)

We have indexing in MongoDB similar to SQL databases, with much more interesting index types such as a MultiKey index which you can apply on Array fields, Geo Spatial indexes and much more..!

What's more that MongoDB gives natively?

This blog post could actually NOT cover everything that MongoDB has, simply because there is SO much to talk about..!

• Aggregation Pipelines - This is the absolute heaven of MongoDB, giving you power of data manipulation and computation inside the query itself such as - Bucketing, grouping, Facets (multi answer with single query thingy), Bucket Auto, GraphLookup (My favourite as it gives you power to do DFS/BFS natively), Redact (access control natively depending on field values itself), and much much more..!
• Native Change Streams - If you need CDC, MongoDB comes out of the box with MongoDB Change Streams which is a much more managed way / interface to access CDC than to directly read the journal. It's super helpful when you have a sharded cluster or replica set or both, where you need to configure multiple Journals and all. This is all abstracted and you can just use the native API provided by MongoDB

• Large File Database Engine - MongoDB supports large file objects to be stored in the database as a Linked List using GridFS Storage Engine, where all you need to do is some config, and the whole implementation is taken care by MongoDB itself.
• MongoDB Atlas - The managed MongoDB Cloud, database as a service is now so much more than just a database. Serverless backend programming, online archival, cold storage, no code charts and analytics, managed triggers and system functions, Atlas search (Full text search engine on your original collection) there is a full world of things there is with Atlas. (Separate post later)

Conclusion

There is just so much about MongoDB, that I can't just stop expressing about..! But if you feel you miss out on so many of these things and wanna learn and explore more, come join me in my 5 Day MongoDB course where I'll be teaching all the basic and important concepts of MongoDB.

Just a warning, seats are limited and I tend to have only small batches to concentrate QnA better. Be sure to book fast..!