When should we use MongoDB?

Question

MongoDB is a NoSQL database which I've found quite easy to use. Recently I had to develop a simple application which needed to collect some data using HTTP requests and store some results after processing the data, and I tried using MongoDB.

From this experience I found it much nicer to use than traditional relational databases and since I'm a developer, and not a DBA, my work was greatly simplified.

Still, sometimes I feel unsure when should I use MongoDB instead of a traditional relational database, like SQL Server or MySQL.

In that case, when we can use MongoDB instead of relational databases? Is there some trully big caveat about MongoDB that makes it improper for some situations?

Answer 1

Basically:

• If you can represent your data in a form of a bunch of documents, MongoDB could be a good choice.

• If you would rather imagine your data as a bunch of interconnected tables, MongoDB may not be a good choice.

Here are two examples which I find illustrative:

• A few years ago, I created a blog engine. Its purpose is to host blog articles, and for every article, store the different versions, some metadata, visit statistics, etc.

  This could be stored as a bunch of tables, but when trying to build a model, it grows very fast to a dozen of tables, if not more. Some SQL queries could get ugly with a lot of joins, and... well, you get the picture.

  The problem here is that there is a central thing—a blog article—and there is all this stuff around the article, which makes it well suited for a document-based database. With MongoDB, modeling the database was extremely easy: one collection holds the blog articles, and a second tiny collection contains the list of users allowed to write articles. Each document within the first collection would contain all the information I need when displaying an article, would it be the name of the author, or the tags.

• Now imagine a very different project. There are some users who can write stuff, and share the stuff written by other users. On a page of a user, you would expect to find both things this user wrote and the ones she shared. There is one constraint: when somebody edits what he wrote in the past, the change appears everywhere where the original text was shared.

  With a document-based approach, it's difficult to find what would be the document. A user maybe? Well, that's a good start. A user document would contain all the things this user wrote. But what about the things she shared?

  A possible way is to put those things in the same document. The problem with this approach is that if somebody edits an entry, the application should walk through every user document in the database in order to edit every occurrence of the old entry. Not counting the data duplication.

  An alternative would be to keep within the user document just the list of entries this user shared (with the ID of the referred user and entry). But now, a different problem would occur: if a user shared thousands of entries from thousands of users, it would require to open thousands of documents to get those entries.

  Or we can model our collection around the entries themselves, each entry referring to its author and having a list of users who shared it. Here again, performance issues could become noticeable when you'll need to walk through all the documents in order to show the ones published by a given user.

  Now, how much tables would you need if you were using a relational database? Right, three. It would be straightforward to model, and also straightforward to use.

Answer 2

Each technology has its advantages.

The advantages of relational databases is that the RDBMS does some things for you, like:

• Enforcing referential integrity ( not allowing the insertion of an invoice detail if the invoice it belongs to doesn't exist)
• Avoid redundancy: things are stored only once.
• Complex queries can be done with a declarative language (SQL) which is mature, time-proven and widely spread.

All that boils down to the fact that you have to write less code because the RDBMS enforces things for you.

Additionally, data independency: often times if you use standard SQL structures and no vendor-specific ones, you can migrate your data from one RDBMS to another with minimal hassle, whereas NOSQL databases are not standardized at all.

On the other hand, one of the advantages of NOSQL databases is that they scale better maintaining performance for millions of rows. They are better suited for document-based storage, i.e. non-structured data. But most applications don't need these features.

Answer 3

For your particular case, MongoDB sounds like a good choice, but there are plenty of scenarios (probably most of them) where it wouldn't be the best choice.

MongoDB is more suited in scenarios that call for reading/writing a lot of data, without much emphasis on transaction safety (if some data occasionally gets lost in a server crash, it's not a big deal), expect to scale big, and don't really have a stable schema.

MongoDB is not suited for scenarios that require:

1. Strong ACID guarantees: MongoDB allows for duplicate data to be stored, inconsistent reads, and even data loss. These things are fine in some applications, but not in most.
2. Multi-Object Transactions: MongoDB does support ACID transactions, but only for a single object/document. This just won't cut it for more complex operations like bank transfers, making a reservation, etc.
3. Traditional BI: there are a lot of BI tools out there that only play well with traditional SQL.
4. SQL: MongoDB has a very specific query language, whereas SQL is very well known by a lot of people (might be an important aspect to consider), can do a lot of complex things (whereas with MongoDB you'd have trouble performing a simple join) and is transferable across a lot of implementations.

MongoDB is faster and will allow you to eke more performance out of the system by eliminating a lot of stuff that RDBMS enforce by default, like integrity checks (note that you can also tweak RDBMS for such purposes, anyway), but the truth is, in most scenarios, it's just not needed. Plus, the trade-off is reliability and flexibility (you'll have trouble if, later on, you decide you need to do more complex operations with existing data).

It all depends on the needs of the application you're building. Is it speed and availability, or safety, reliability and flexibility. You have to know where in your data (and in your data's connections) lies more value. If you don't know yet, it's probably best if you choose something that won't paint you into a corner in the future, and will allow you to add the features and perform the operations your application needs.

Answer 4

MongoDB is useful in order to store the whole structured data needed to build a given instance of a web page. You can retrieve the data for a given page, pass it to your client application which can then render it.

In such a context, MongoDB is very fast and reliable. But never forget you don't have relational information in your database. Which means if you change something in the structure of your webpage, you could be unable to fill the holes in your already stored pages because you don't have the data needed to do so. More on this here: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

Answer 5

MongoDB is great when you can represent your data as independent "packages" of information. You have google maps ZIP codes, embedded in the ZIP code are companies and inside the companies are employees. All the zip codes are independent from each other and you can get the whole information in a simple, pretty and fast way. That is a good scenario for a nonSQL solution.

Once said that, I totally disagree with the current trend I'm looking that implies that MongoDB is a kind of post and superior solution to RDBMS and noSQL must be your solution by default. All that is absurd. MongoDB is a niche database and 90% of the projects are relational and need a RDBMS option because you want a powerful query solution like SQL to generate your reports and look for disperse data: "joins" are a pro, not a con. Besides, modern RDBMS support BSON collections and geospatial integration so maybe the niche for noSQL is even narrower now.