To the disdain of some, NoSQL databases are well and truly here to stay and everyday proving their worth. The number one question I see being asked is: can I replace MySQL and use MongoDB instead?
A couple of years ago I would have told you no. In-fact, I would have probably argued with you about using a NoSQL database for more simple tasks that don’t require table joins and advanced queries instead of using it as a fully-blown RDBMS replacement. It’s 2014 and times change, especially as existing solutions die or mature.
Everything discussed onwards is in relation to MongoDB and MySQL. Most of this could apply to other NoSQL databases, but we will focus on MongoDB for this article at least.
Understanding Limitations
Before you decide to switch, you’ll need to understand the limitations first. If you blindly decide to use MongoDB and spit in the face of MySQL, you can probably guess what will happen. You will learn pretty quickly you shouldn’t rush decisions like these.
Disk space
MongoDB can consume a lot of disk space as your data grows. When you create a database a file called dbname.0 will be created automatically and by default it will be 64mb. When half of this file has been used, MongoDB will create another file double the size called dbname.1 at a size of 128mb and so on until it reaches a final size of 2048mb. Each subsequent database file will be 2048mb and no longer double.
This isn’t a fault of MongoDB, but it is something that catches many first-timers by surprise.
Databases cannot be renamed
This is a known issue and there is a ticket on the MongoDB task tracker here. Keep this in mind when naming your databases or you will encounter this annoying issue. For most this might not even be an issue, but for some it is and a limitation regardless.
Be patient on this one, it is planned, but the ticket was created in 2010…
SSD or the slow-way
You will notice significant speed improvements if your server has solid state drives. Because MongoDB uses a combination of RAM and disk-space, a solid state drive will offer significant performance improvements and throughput. While standard hard disks are still fast enough, faster drives means faster I/O and thus significantly quicker queries when querying your MongoDB instance(s).
There is a link here on the official MongoDB documentation detailing all of the limits of using MongoDB. I suggest you read through and ensure there are no deal-breakers here for moving off MySQL.
Understanding Differences
The syntax and way things are done in MongoDB is considerably different to that of a traditional RDBMS like MySQL. The underlying concepts of storage are relatively the same, but the terminology is different (this applies to most NoSQL databases.
MySQL stores data in a table
MongoDB stores data in a collection
MySQL stores a single item of information in a row inside of a table
MongoDB stores a single item of information in a document or BSON document inside of a collection
Documents are implicitly created upon a successful first .insert(), although there is a method for creating documents if needed. There is no querying language, everything is handled through the use of object methods.
Transactions do kind of exist in MongoDB
A common misconception of MongoDB stemming back to older versions is that it does not support transactions. This is actually untrue. MongoDB doesn’t call them transactions, they’re called two-phase commits and they work very similarly.
While two-phase commits might not be perfect and not a 1:1 match for transactions and require some additional application logic, they do work and can be used as a replacement for transactions if you need to implement a transaction like process into your application (dealing with monetary values and that kind of thing).
Read more about two-phase commits here
Do you fit a valid MongoDB use-case?
Don’t be so quick to rush out and replace MySQL with MongoDB, you need to assess if your use-case will fall within one of the valid cases for MongoDB.
Keep in mind that you don’t have to use one or the other. MongoDB can be used alongside MySQL for a particular task or set of tasks, whilst MySQL does other tasks of your application that MongoDB might not be the better fit for.
You can mix and match databases, just ensure you devote the appropriate resources to whatever you choose to efficiently use them.
Rapid prototyping
If your development workflow consists of a prototyping phase, MongoDB can prove invaluable when dealing with a high-level concept for an application where the final database structure hasn’t been determined. Because you don’t have to keep modifying the database every time you add or remove a feature, you can focus on the application itself.
Content management system
Because of its nature and way it works with different forms of content, MongoDB would be perfect for use as a database for a content management system. Its ability to store different pieces of data and media metadata without requiring a schema means your posts can have different attributes to your tables and media as well whilst all coexisting in the same collection.
Inventory/stock Management
Store information about multiple items/stock in the one database with support for unique attributes only relevant to a particular item. This is a perfect fit for MongoDB, working with data that doesn’t have a defined structure. A toaster isn’t the same as a lawn mower, so the attributes for either will be substantially different (except for a few fields like name and price).
Machine generated data
Different devices comprised of different sensors all emitting varying pieces of information. MongoDB is the perfect fit for a monitoring application that is responsible for monitoring different pieces of information from various sensors and machines. Think of an airplane, it is comprised of thousands of different sensors all over the plane capturing and emiting different pieces of info. A schema database like MySQL would be a nightmare, especially if you install a new sensor and need to add an existing field.
Rapid writes
MySQL falters when it comes to rapid database writes, most RDBMS’s do (even when tweaked for write performance). If you need to write large amounts of data very quickly, MongoDB is probably the better choice.
Working with inconsistent/unstructured data
There is a reason they call MongoDB and most NoSQL databases document databases: they work extremely well in situations where data doesn’t fit a particular format. If you are storing documents that vary in content and no two pieces of data are the same, MongoDB is a perfect fit because it is schema-less and allows you to create fields on the fly.
Invalid MongoDB use-cases
There are situations where MongoDB still could work, but might end up causing you more headaches in the long run.
Relational data
Even though MongoDB can work with relational data (multiple pieces of information that relate to one another) through document embedding and references, it feels hacky and each approach has its own caveats. Embedding of a document makes it harder to relate a piece of information to other pieces of information due to it being embedded within a document already.
I am not saying a relational structure in MongoDB is impossible, but it isn’t ideal either.
Graph databases
While I don’t doubt you can probably knock something together in MongoDB, you will be met with resistance trying to make MongoDB work as a graph database (traversing paths and mapping relationships between multiple nodes/edges of data). Use something like Neo4j in this instance, not even MySQL is fit for the purpose of graphing.
Social networks
This article say no more.
