What is MongoDB: Explaining the Rise of NoSQL

Traditional relational databases have been the bread-and-butter of data storage for decades. MySQL, PostgreSQL, and Microsoft SQL Server have been the leading database technologies for a long time, and there’s no indication they’ll be going away any time soon. Conventional databases are still a highly effective way to store and access information. However, a new type of database, known generally as NoSQL, is on the rise. Perhaps chief among the providers of NoSQL, non-relational databases is MongoDB, a relatively new contender in the database space.

MongoDB completely changes how data is stored, queried, and retrieved from traditional database systems. To be honest, the changes make MongoDB unsuitable for many applications, and for the majority of projects a relational database is still the best option. In this article, however, we’ll explore the advantages of non-relational databases and the scenarios where MongoDB is seeing increased interest. By the end of this article, you’ll understand what MongoDB is and why developers are increasingly using it in specific applications.

SQL vs MongoDB

The differences between MongoDB and traditional SQL-based databases are fundamental. When you use Postgres, MySQL, or SQL Server to power a project, you store data in a set of tables that often cross-reference one another to maintain relationships between data points.

MongoDB, on the other hand, doesn’t maintain these relationships. It’s a non-relational database, and anything you want to know about a record needs to be contained within that record itself. That said, you can choose to include data models and linking fields in your collections when creating them, but it’s up to you to enforce those models and keep links working between your MongoDB collections.

A little bit of terminology: a record in MongoDB is known as a “document.” Documents can be grouped together into “collections.”

No Schema = Fast Setup

A major concept to understand about MongoDB is it stores information in a stream. Whereas traditional databases require you to define a schema (the structure of tables and columns), a MongoDB database can take in any information you want it to store, regardless of structure or relationship. A typical MongoDB record looks like a JSON object, with keys and values mapped to one another inside a dictionary. Each record can be distinct and records don’t have to share any keys (fields) in common.

This means that you spend no time setting up the MongoDB structure before you begin a project. You can immediately start creating, reading, updating, and deleting (CRUD) documents at will.

MEAN Stack

The fast setup time and flexible nature of MongoDB has made it attractive to fast-moving startups and apps that value quick deployments and low overhead on database administration. While these startups face big challenges if they want to move to more enterprise-ready traditional databases that offer more complex queries and summary reporting, they’re often willing to take onboard the stability concerns associated with MongoDB in exchange for fast development.

This type of quick-to-launch development of web applications, especially single-page applications, has become so prevalent that MongoDB has become a standard part of a technology stack known as MEAN. MEAN uses MongoDB (M) as its database for storing user information. It then uses Express.js (E) and Angular (A) to build the responsive application atop a Node.js (N) backend.

Since all four of these technologies are written in JavaScript, the MEAN stack has the added benefit of only needing one language for all development, front-end, back-end, and database queries. Similarly, a MERN stack, using React instead of Angular, has also become popular.

Datasets Larger Than a Single Server

Another growing use case for MongoDB is for datasets larger than can be processed on a single server. MongoDB supports sharding of a database, allowing multiple servers to run concurrently and process separate tasks individually. Typically, the benefits of MongoDB sharding start to become apparent when running more than ten servers concurrently to store huge datasets and process requests.

However, setting up a sharded MongoDB database can be a technical challenge, and they’re difficult to make changes to once implemented. Recombining and migrating sharded datasets of a massive size tends to be unmanageable, so make sure your solution really requires sharding (not just adding hardware or other optimizations to your existing SQL-based server), before making the switch.

Replication & Transparent Failover

MongoDB also includes tools for replicating data and setting up failover procedures for your application to ensure high availability. To take full advantage of these built-in abilities, you’ll need to run at least three servers. One of these will be your primary server where all writes and queries will be handled. The other two will replicate the primary. If the primary goes down, one of your secondaries will automatically become the new primary, now accepting writes and deletes. This assumes that you’ve properly provided the IPs of all three servers to the application driver.

Drawbacks

Despite its benefits, MongoDB’s architecture can make it difficult to use. For instance, MongoDB only recently implemented ACID transactions in their 4.0 release. Previously, MongoDB couldn’t guarantee that concurrent transactions and sessions were processed reliably. Even still, the MongoDB transaction model rejects requests made to a document currently blocked for changes, so any rejected concurrent requests must be re-executed rather than scheduled to happen sequentially.

In addition, aggregation queries are a pain in MongoDB, especially across collections. MongoDB does provide tools to make this critical functionality easier, called its Aggregation Pipeline, but it’s certainly not as easy as writing a SQL GROUP BY command.

Mongo Moving Forward

There are certainly valid arguments for and against using MongoDB in production. Ultimately, it depends what you’re building and what your priorities are for your database. MongoDB has some advantages for quick startup time and sharded computing. However, it’s not a good solution for all applications, and it will not supplant relational databases as the primary database structure any time soon.