The Top 4 Reasons Why You Should Use MongoDB
Rate this article
I also introduced you to Ron. Let's take a moment and return to Ron. Ron is pretty set in his ways. For example, he loves his typewriter. It doesn't matter that computers are a bajillion times more powerful than typewriters. Until someone convinces him otherwise, he's sticking with his typewriter.
Maybe you don't have a love for typewriters. But perhaps you have a love for SQL databases. You've been using them for years, you've learned how to make them work well enough for you, and you know that learning MongoDB will require you to change your mindset. Is it really worth the effort?
In this post, we'll examine the top four reasons why you should use MongoDB:
You can scale cheaper with MongoDB. Why?
Let's begin by talking about scaling SQL databases. Typically, SQL databases scale vertically-when a database becomes too big for its server, it is migrated to a larger server.
A few key problems arise with vertical scaling:
- Large servers tend to be more expensive than two smaller servers with the same total capacity.
- Large servers may not be available due to cost limitations, cloud provider limitations, or technology limitations (a server the size you need may not exist).
- Migrating to a larger server may require application downtime.
When you use MongoDB, you have the flexibility to scale horizontally through . Sharding is a method for distributing data across multiple servers. When your database exceeds the capacity of its current server, you can begin sharding and split it over two servers. As your database continues to grow, you can continue to add more servers. The advantage is that these new servers don't need to be big, expensive machines-they can be cheaper, commodity hardware. Plus, no downtime is required.
Your queries will typically be faster with MongoDB. Let's examine why.
In these three small tables, the join will be very fast. However, as the tables grow and our queries become more complex, joining tables together becomes very expensive.
Recall our rule of thumb when modeling data in MongoDB: data that is accessed together should be stored together. When you follow this rule of thumb, most queries will not require you to join any data together.
Continuing with our earlier example, if we want to retrieve Leslie's information from MongoDB, we can simply query for a single document in the
Userscollection. As a result, our query will be very fast.
As our documents and collections grow larger, we don't have to worry about our queries slowing down as long as we are using indexes and continue following our rule of thumb: data that is accessed together should be stored together.
Requirements change. Sometimes the changes are simple and require only a few tweaks to the user interface. But sometimes changes go all the way down to the database.
To add a new
schoolcolumn in our SQL database, we're going to have to alter the
Userstable. Executing the
Alter Tablecommand could take a couple of hours depending on how much data is in the table. The performance of our application could be decreased while the table is being altered, and we may need to schedule downtime for our application.
Now let's examine how we can do something similar in MongoDB. When our requirements change and we need to begin storing the name of a user's school in a
Userdocument, we can simply begin doing so. We can choose if and when to update existing documents in the collection.
If we had implemented schema validation, we would have the option of applying the validation to all inserts and updates or only to inserts and updates to documents that already meet the schema requirements. We would also have the choice of throwing an error or a warning if a validation rule is violated.
With MongoDB, you can easily change the shape of your data as your app evolves.
To be honest with you, this advantage is one of the biggest surprises to me. I figured that it didn't matter what you used as your backend database—the code that interacts with it would be basically the same. I was wrong.
MongoDB documents map to data structures in most popular programming languages. This sounds like such a simple thing, but it makes a humongous difference when you're writing code.
A friend encouraged me to test this out, so I did. I implemented the code to retrieve and update user profile information. My code has some simplifications in it to enable me to focus on the interactions with the database rather than the user interface. I also limited the user profile information to just contact information and hobbies.
I wrote the code in Python, but, don't worry if you're not familiar with Python, I'll walk you through it step by step. The concepts will be applicable no matter what your programming language of choice is.
Let's begin with the typical top-of-the-file stuff. We'll import what we need, connect to the database, and declare our variables. I'm going to simplify things by hardcoding the User ID of the user whose profile we will be retrieving rather than pulling it dynamically from the frontend code.
So far, the code is pretty much the same.
Let's begin by implementing the code for MySQL.
When we execute the query, a result is returned for every user/hobby combination. When we call
fetchone(), we get a dictionary like the following:
Because we joined the
Hobbiestables, we have a result for each hobby this user has. To retrieve all of the hobbies, we need to iterate the cursor. We'll append each hobby to a new
hobbiesarray and then add the
hobbiesarray to our
Now let's implement that same functionality for MongoDB.
Since we stored all of the user profile information in the
Userdocument, we don't need to do any joins. We can simply retrieve a single document in our collection.
Here is where the big advantage that MongoDB documents map to data structures in most popular programming languages comes in. I don't have to do any work to get my data into an easy-to-work-with Python Dictionary. MongoDB gives me all of the results in a Python Dictionary automatically.
And that's it—we're done. What took us 12 lines for MySQL, we were able to implement in 1 line for MongoDB.
userdictionaries are now pretty similar in both pieces of code.
Now that we have retrieved the user's profile information, we'd likely send that information up the stack to the frontend UI code.
When Leslie views her profile information in our application, she may discover she needs to update her profile information. The frontend UI code would send that updated information in a Python dictionary to the Python files we've been writing.
To simulate Leslie updating her profile information, we'll manually update the Python dictionary ourselves for both MySQL and MongoDB.
Now that our
userdictionary is updated, let's push the updated information to our databases.
Let's begin with MySQL. First, we need to update the information that is stored in the
Second, we need to update our hobbies. For simplicity, we'll delete any existing hobbies in the
Hobbiestable for this user and then we'll insert the new hobbies into the
Now let's update the user profile information in MongoDB. Since the user's profile information is stored in a single document, we only have to do a single update. Once again we will benefit from MongoDB documents mapping to data structures in most popular programming languages. We can send our
userPython dictionary when we call
update_one(), which significantly simplifies our code.
What took us 15 lines for MySQL, we were able to implement in 1 line for MongoDB.
In this example, we wrote 27 lines of code to interact with our data in MySQL and 2 lines of code to interact with our data in MongoDB. While fewer lines of code is not always indicative of better code, in this case, we can probably agree that fewer lines of code will likely lead to easier maintenance and fewer bugs.
The examples above were relatively simple with small queries. Imagine how much bigger the difference would be for larger, more complex queries.
MongoDB documents mapping to data structures in most popular programming languages can be a huge advantage in terms of time to write, debug, and maintain code.
In this post, we discussed the top four reasons why you should use MongoDB:
Be on the lookout for the final post in this series where I'll discuss the top three things you need to know as you move from SQL to MongoDB.