Why and When Use MongoDB
Businesses around the world are changing their working dynamics, every business is in a race to perform better. In this rapidly upgrading world every business needs intelligence, futuristic approach and a system that provides performance statistics
Hey there, in this article I am gonna tell you when you should use MongoDB and why. I will share my personal experience with MongoDB like why I chose MongoDB (specially the reason switching from MySQL), what challenges I faced while switching , what things you need to know about MongoDB before using it. Let’s start with a brief Introduction of MongoDB and I promise It will really be a brief intro and I’ll try to make it more related with my topic, so don’t worry I will not bore you :)
MongoDB
MongoDB is a non-relational database that stores data in BSON ( Binary Javascript Object Notation ) type but shows as JSON (Javascript Object Notation ). MongoDB uses a collection of documents instead of a table consisting of rows and columns in a traditional SQL database. Each document provides information about an object of same or different type because MongoDB does not require any specified schema or model unlike a traditional SQL database which requires a specified schema for every row in a table. So I can say that you can store information about different types of objects or the same type of objects with less or more or different properties. Let’s try to understand this with an example
Suppose you are working for an automobile manufacturer and you need to store information about their vehicles. Now if we see we can have different types of vehicles having some similar properties like seating_capacity , no_of_wheels etc but different vehicles also have some more or less properties like a truck could have multiple fuel tanks but a car only can have one so what if you need to store capacity of each tank ? In a traditional SQL database you need to create a separate table for it and make a relation here between these two tables but in MongoDB you have multiple solutions to do this you can create multiple fields for multiple tanks how many you need or you can create an array of fuel tanks BINGO…
There could be many other better examples but i’ll stick with this
Why I choose MongoDB
I think now you have a little introduction about MongoDB. Let’s see that in a real software world where we should use MongoDB. Let me share my personal experience with MongoDB and why I choose it and I ll provide you a brief list of points at end for choosing MongoDB as database
As I am a full stack software engineer, I am working in a company that develops Contact Center solutions. My company gave me a task to revamp the backend structure of their OMNI channel solution (which was already running with MySQL database). I started with gathering requirements about the current system and why we need to revamp it. After a bundle of meetings with the team and management we decided to go with MongoDB as a database. Following are the reasons behind choosing MongoDB
- We have to deal with multiple communication channels and every channel has its own unique less or more properties so we cannot stick to a specific schema
- We need a word text based search on our daily transactional data and MongoDB has this built in feature without using any third party service like elastic search (although elastic search provides many other features but we need only a text search)
- We have a feature of wide range of reporting and customised dashboards and for this MongoDB provides aggregation to calculate complex results
- Other reasons includes MongoDB’s speed , efficiency , sharding, multi indexing feature and many more
Why and When you should use MongoDB
Following points provide you the answer that when to use MongoDB
- When you have unstable database schema use MongoDB schema less approach
- When you have massive amount of data use MongoDB as it supports sharding of data
- When you need JavaScript friendly database
- When you need cloud friendly database
- When you need to store your data in some categories like facebook store region wise data
- When you need speedy results on complex calculations use MongoDB Aggregation
- When you don’t want to make relations / joins in your data
- When you need a built-in database word text search
- When you have scalable software application architecture use benefit from MongoDB’s horizontal scalable architecture
- When you cannot compromise on data availability use MongoDB as it can run in cluster and provides backup when primary database fails
Anything that has pros also has cons so following are some major cons and cautions of MongoDB
- It uses high memory due to its cache mechanism and stores indexes in memory
- Each document has a limit of 16 MB
- MongoDB does not support joins and relations between data
- You have to be very careful and make proper indexes when you are doing multiple operations in a single query specially sort operation running on a big data set. e.g. If you are sorting data date wise (in descending order) along with text search and the fetch result is also large you will experience a dead slow MongoDB query as it will do sort operation in memory
- You also have to be very careful when you are using comparison operators like $eq, $lt, $lte, $gt, and $gte inside $expr because it could slow your query as this operator does not use indexes in some cases when working with comparison operators
Don’t worry you can overcome the above cautions by using best practices. As I did and even doing also :)
Good Bye
I hope you find this article helpful , I provide the above information best to my knowledge and experience. There are a lot of articles on MongoDB learning in my list for the future. See you in the next article.