The Top 4 Reasons Why You Should Use MongoDB

#Scale Cheaper

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. 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.

#Query Faster

Your queries will typically be faster with MongoDB. Let's examine why.

Even in our simple example in the previous post where we modeled Leslie's data in SQL, we saw that her information was spread across three tables. Whenever we want to query for Leslie's information, we'll need to join three tables together.

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 Users collection. 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.

#Pivot Easier

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.

In the previous post in this series, we discovered—after implementing our application—that we needed to store information about Lauren's school. Let's take a look at this example a little more closely.

To add a new school column in our SQL database, we're going to have to alter the Users table. Executing the Alter Table command 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 User document, 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.

#Program Faster

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.

Below is a comparison of my implementation using MySQL and MongoDB.

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.

1
import mysql.connector
2
3
# CONNECT TO THE DB
4
mydb = mysql.connector.connect(
5
   host="localhost",
6
   user="root",
7
   passwd="rootroot",
8
   database="CityHall"
9
)
10
mycursor = mydb.cursor(dictionary=True)
11
12
# THE ID OF THE USER WHOSE PROFILE WE WILL BE RETRIEVING AND UPDATING
13
userId = 1

1
import pymongo
2
from pymongo import MongoClient
3
4
# CONNECT TO THE DB
5
client = MongoClient()
6
client = pymongo.MongoClient("mongodb+srv://root:rootroot@mycluster.mongodb.net/test?retryWrites=true&w=majority")
7
db = client.CityHall
8
9
# THE ID OF THE USER WHOSE PROFILE WE WILL BE RETRIEVING AND UPDATING
10
userId = 1

1
sql = "SELECT * FROM Users LEFT JOIN Hobbies ON Users.ID = Hobbies.user_id WHERE Users.id=%s"
2
values = (userId,)
3
my cursor.execute(sql, values)
4
user = mycursor.fetchone()

1
{u'city': u'Pawnee', u'first_name': u'Leslie', u'last_name': u'Yepp', u'user_id': 1, u'school': None, u'longitude': -86.5366, u'cell': u'8125552344', u'latitude': 39.1703, u'hobby': u'scrapbooking', u'ID': 10}

1
hobbies = []
2
if (user["hobby"]):
3
  hobbies.append(user["hobby"])
4
del user["hobby"]
5
del user["ID"]
6
for result in mycursor:
7
  hobbies.append(result["hobby"])
8
user["hobbies"] = hobbies

1
user = db['Users'].find_one({"_id": userId})

1
{
2
   'city': 'Pawnee',
3
   'first_name': 'Leslie',
4
   'last_name': 'Yepp',
5
   'school': None,
6
   'cell': '8125552344',
7
   'latitude': 39.1703,
8
   'longitude': -86.5366,3
9
   'hobbies': ['scrapbooking', 'eating waffles', 'working'],
10
   'user_id': 1
11
}

1
{
2
   'city': 'Pawnee',
3
   'first_name': 'Leslie',
4
   'last_name': 'Yepp',
5
   'cell': '8125552344',
6
   'location': [-86.536632, 39.170344],
7
   'hobbies': ['scrapbooking', 'eating waffles', 'working'],
8
   '_id': 1
9
}

1
user.update( {
2
   "city": "Washington, DC",
3
   "latitude": 38.897760,
4
   "longitude": -77.036809,
5
   "hobbies": ["scrapbooking", "eating waffles", "signing bills"]
6
   } )

1
user.update( {
2
   "city": "Washington, DC",
3
   "location": [-77.036809, 38.897760],
4
   "hobbies": ["scrapbooking", "eating waffles", "signing bills"]
5
   } )

1
sql = "UPDATE Users SET first_name=%s, last_name=%s, cell=%s, city=%s, latitude=%s, longitude=%s, school=%s WHERE (ID=%s)"
2
values = (user["first_name"], user["last_name"], user["cell"], user["city"], user["latitude"], user["longitude"], user["school"], userId)
3
mycursor.execute(sql, values)
4
mydb.commit()

1
sql = "DELETE FROM Hobbies WHERE user_id=%s"
2
values = (userId,)
3
mycursor.execute(sql, values)
4
mydb.commit()
5
6
if(len(user["hobbies"]) > 0):
7
   sql = "INSERT INTO Hobbies (user_id, hobby) VALUES (%s, %s)"
8
   values = []
9
   for hobby in user["hobbies"]:
10
      values.append((userId, hobby))
11
   mycursor.executemany(sql,values)
12
   mydb.commit()

1
result = db['Users'].update_one({"_id": userId}, {"$set": user})

#Wrap Up

In this post, we discussed the top four reasons why you should use MongoDB:

• Scale Cheaper
• Query Faster
• Pivot Easier
• Program Faster

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.