Why I recommend MongoDB
Before we begin to develop an application, of any kind, any scale; we need to first thoroughly understand the requirement, to be more confident on what we are going to build. Few things we need to reflect on and evaluate at the beginning of the project – the programming language which we choose for the app, the backend architecture and framework on which the app will be built, the server on which we host and run the app, the configuration of the server and finally the choice of database and its design. The overall quality of the application, in terms of stability and reliability at varying levels of usage, is directly proportional to the above factors.
In this post, I’d be sharing few insights on making the right choice of database for your app; as storing, retrieving and updating data in a manner that the overall user experience on the app is seamless and smooth, is one of the most important challenges we need to address and solve as web developers. Whether it’s a relational or non-relational database, it’s entirely dependent on the nature of the app, data and usage.
Relational Versus Non-relational DB
A few years ago, when businesses were not much reliant on technology, it was enough to have a website with static data on few pages without much analytics or data mining. But today, websites and apps need visually rich – interactive pages, with a variety of fonts, videos, audios, images and deep integration with social media, to get users attention. Real-time data for decision making is becoming more important. Building websites & apps for businesses that run on technology now go through rapid changes to meet market needs.
In short, to develop products that are constantly evolving and dynamically changing, a traditional relational database fails to meet the need, as the relationships between entities are rigid, a small change in attributes / columns, require a lot of change in the Model(where the business logic resides). With a relational database, it’s very difficult to add new content, new attribute or a new feature, without disrupting performance or taking the database offline. With non-relational databases (like MongoDB), you can store any type of content, incorporate any kind of data in a single database, make changes and enhancements to the application faster.
My experience with MongoDB
For a marketplace portal called lawmatters.com (that recently went live), I had to store, fetch and update data for about 10 million lawyers. I used mongoDB, as querying would be faster with Mongo compared to SQL, given the volume of data I had to handle. There were few reasons why I preferred Mongo to SQL:
- In future when the number of users registered on the application increases, there is no need to worry about the database, as MongoDB can scale horizontally using sharding and replica sets.
- If we want to add more functionality to the application, there is no need to change the whole DB structure, as MongoDB is easy to maintain.
- One interesting thing is, MongoDB’s Geospatial Indexes – which made listing based on users browsing location extremely easy.
When MongoDB may not fit best
- Mongo or any other NoSQL solutions is not a good choice if you need full ACID support or strong schema enforcement – in this case you can better go for a relational database such as MySQL or PostgreSQL.
- If you are doing deep, computation heavy analytics you can opt for something like Hadoop.
- If high write availability is critical and conflicts are okay, you could go for a Dynamo-style system like Cassandra and Riak.
