Is MongoDB Really Superior to MySQL?

shutterstock_208391014

When MongoDB came out six years ago, the NoSQL fad was in full swing. Rather than rely on a table-based relational database structure, MongoDB utilizes BSON, or “Binary JSON,” which many users found attractive; the platform quickly grew into a leader among NoSQL databases.

As more people took the MongoDB plunge, however, many began to complain about various issues, including its lack of speed. For the past few years, people have debated whether that initial hype was worth it. Now that the technology’s reached maturity, and many of its most annoying bugs have been squashed, that question can be confronted head on: Is it worth using MongoDB when you can stick with an old, rugged SQL standby such as MySQL?

Before we dig into the issue, let’s look at the purpose behind each technology:

  • MySQL is for storing relational data
  • MongoDB is for storing documents in JSON and BSON

I’ve seen a lot of developers favor a NoSQL solution such as MongoDB for the bulk of their work, because they assume that MySQL remains unable to accomplish certain tasks. “My data has a unique layout, that can’t be put into relational, tabular form,” these people claim. But if you do some digging, you’ll often find that people are able to accomplish whatever they need with a relational database, provided they code carefully and don’t try to take shortcuts. The format is more versatile than many people will admit; for decades, people have created complex structures and stored them in relational databases just fine.

Check out the latest database-related jobs.

Developers also dislike certain aspects of MongoDB. It doesn’t allow joins, for example, which leads people to stuff in gigantic documents with lots of repeated data, creating a royal mess. Making things worse is MongoDB’s insistence on restricting access; if you’re adding customer orders to a giant document, other people can’t add rows until you’re finished. With MySQL, on the other hand, people in that situation could add orders simultaneously. (Those who insist on bringing joins-like functionality to MongoDB can put records in separate documents, although this can require some creative coding on the developer’s part.)

Even those companies and prominent developers who like MongoDB don’t rely on it for every database-related issue. For example, some firms have a real problem with what they perceive as MongoDB’s lack of ACID compliance. If your project requires large amounts of normalized data, with loads of reads and writes, it’s probably best to go with MySQL, rather than “trying to make it work” in MongoDB.

As with any popular software platform, both MongoDB and MySQL suffer from perception issues, some of which are, frankly, unfair. People claim that MySQL doesn’t easily scale horizontally, and that the only option for doing so is to increase memory on a single MySQL server. That’s an outmoded claim; there are plenty of ways to scale. In a similar fashion, a lot of people insist that MongoDB will crash and cause massive data loss; while that was an issue in the past, developers have squashed many of the related bugs.

So is it worth using MongoDB over MySQL? Not in every situation. When deciding which is better suited to your project, spend time studying the documentation for both, and try working with a dataset in MongoDB to see whether it fits your needs. Understand the role that benchmarks play: For instance, if you’re building a website that does a handful of database queries per second, does it matter which database can perform a couple thousand per second? Bottlenecks can have a huge impact on application performance; it pays to read up on how to optimize your implementation, regardless of which one you choose.

I’ve been engaged in SQL programming since around 1990. When I found MongoDB, it was like a godsend, as it allowed me to store complex structures easily. Over time, however, I realized I was relying on MongoDB as a sort of a crutch, and moved back to MySQL. Today, I use MongoDB when I need document storage that doesn’t require continual tweaks of small fields, but I generally use MySQL for most of my work.

But my situation doesn’t apply to everyone: Explore both, learn them well, and you’ll find what works best for your needs.

Image Credit: Denis Vrublevski/Shutterstock.com

Comments

3 Responses to “Is MongoDB Really Superior to MySQL?”

July 13, 2015 at 11:58 pm, Morgan Tocker said:

Hi Jeff,

Worth mentioning perhaps: MySQL 5.7 has a JSON data type which will allow you to store unstructured data. 5.7 is in release candidate now.

Reply

July 16, 2015 at 8:29 am, Michael Powell said:

The second paragraph critiquing the difference in the choice between NoSQL and (Any)SQL (whether MySQL, SQL Server, etc), is only partially accurate IMO.

That I know of, recent versions of MongoDB do permit data to be organized as either “referenced” (loosely join-able) or embedded documents. There’s no right answer here, but that can have serious performance implications. My command of their NoSQL verbiage is clumsy, however, these sorts of decisions are not at all trivial. My best advice is when making this kind of decision, run with it; but as with all decisions, careful they don’t end up making you.

I believe most NoSQL systems are much better readers than they are writers. What do I mean by that? The cost for writing is much more expensive than the cost for reading. Your mileage may vary depending on the provider.

The strongest case I’ve heard for NoSQL is as an analytical tool; complementing existing, “traditional” relational databases, not necessarily to replace them altogether. Especially when you pause to consider stacks like HADOOP, which, for valid reasons of its own, has a massive overhead, storing data in triplicate.

Interesting article, thank you.

Reply

July 17, 2015 at 12:36 pm, Someone said:

The author has not taken into consideration that MongoDB is webscale.

Reply

Post a Comment

Your email address will not be published.