Are document-oriented databases meant to replace relational databases?

Question

Recently I've been working a little with MongoDB and I have to say I really like it. However it is a completely different type of database then I am used. I've noticed that it is most definitely better for certain types of data, however for heavily normalized databases it might not be the best choice.

It appears to me however that it can completely take the place of just about any relational database you may have and in most cases perform better, which is mind boggling. This leads me to ask a few questions:

1. Are document-oriented databases being developed to be the next generation of databases and basically replace relational databases completely?
2. Is it possible that projects would be better off using both a document-oriented database and a relational database side by side for various data which is better suited for one or the other?
3. If document-oriented databases are not meant to replace relational databases, then does anyone have an example of a database structure which would absolutely be better off in a relational database (or vice-versa)?

Antarctica

The short answer: no. – Psychoanalysis

Also of interest: #337844 – Longford

I think that this kind of "short answer" is of very little use for us :P – Clamatorial

Answer 1

Are document-oriented databases have been developed to be the next generation of databases and basically replace relational databases completely?

No. Document-oriented databases (like MongoDB) are very good at the type of tasks that we typically see in modern web sites (fast look-ups of individual items or small sets of items).

But they make some big trade-offs with relational systems. Without things like ACID compliance they're not going to be able to replace certain RDBMS. And if you look at systems like MongoDB, the lack of ACID compliance is a big reason it's so fast.

Is it possible that projects would be better off using both a document-oriented database and a relational database side by side for various data which is better suited for one or the other?

Yes. In fact, I'm running a very large production web-site that uses both. The system was started in MySQL, but we've migrated part of it over to MongoDB, b/c we need a Key-Value store and MySQL just isn't very good at finding one item in a 150M records.

If document-oriented databases are not meant to replace relational databases, then does anyone have an example of a database structure which would absolutely be better off in a relational database (or vice-versa)?

Document-oriented databases are great storing data that is easily contained in "key-value" and simple, linear "parent-child" relationships. Simple examples here are things like Blogs and Wikis.

However, relational databases still have a strong leg up on things like reporting, which tends to be "set-based".

Honestly, I can see a world where most data is "handled" by Document-oriented database, but where the reporting is done in a relational database that is updated by Map-reduce jobs.

Hortative

Excellent response, marked as the answer because you actually answered all of my questions. Thank you. – Antarctica

@Gates VP what does "set-based" mean when talking about relational databases, can you explain it a little bit, thanks~ – Romanaromanas

Answer 2

This is really a question of fitness for purpose.

If you want to be able to join some tables together and return a filtered set of results, you can only do that with a relational database. If you want mind-bending performance and have incredible volumes of data, that's when column-family or document-oriented databases come into their own.

This is a classic trade-off. Relational databases offer you a whole suite of features, which comes with a performance cost. If you couldn't join, index, scan or perform a whole other list of features, you remove the need to have any view over ALL data, which gives you the performance and distribution you need to crunch serious data.

Also, I recommend you follow the blogs of Ayende Rahien on this topic.

http://ayende.com/blog/

Excalibur

I'll be sure to take a look at the blog, however would you suggest possibly using both then? – Antarctica

If you have an "immense volume demand" for a small part of your application landscape, you would only replace this part with the document-oriented database and keep the relational database and all of its features where the performance isn't a problem. – Excalibur

Answer 3

@Sohnee is spot on. I might add that relational databases

• are excellent for retrieving information in unexpected combinations -- even if that occasionally leads to the Bad Idea of extensive reports being run on time-sensitive production systems rather than on a separate data warehouse.
• are a mature technology where you can easily find staff and well tested solutions to any number of problems (including the limitations of the relational model, as well as the imperfect implementation that is SQL).

Ask yourself what you want to do, and what qualities are important to you. You can do everything programming related in shell scripts. Do you want to?

Hairdresser

Answer 4

I keep asking the same question, which is what landed me here. I use both MySQL and MongoDB (not in tandem currently, though its an idea). I have to honestly say I'm very happy to never touch MySQL again. Sure there's the "ACID" compliance, but have you ever run into the need to repair your tables with MySQL? Have you ever had a corrupted database? It happens. Have you ever had any other issues with MySQL? Any lock contentions or dead locks? Any problems with clustering? How easy was it to setup and configure?

MongoDB...You turn it on and it's done....Then it's autosharding. It's incredibly simple and it's also incredibly fast. So think about that. Your time.

No, they don't have JOINs but it's a completely incorrect statement to say that it discounts more than 99% of data management needs. I often get opposition when trying to explain MongoDB, people even snickering. Let's just face it. People don't want to learn new things and they think that what they know is all they need. Sure, you can get away using MySQL the rest of your life and build your web sites. It works, we know it works. We also know it fails. If it didn't, you'd never ask the question and we probably wouldn't see so many document oriented databases. We know that yes it does scale but it's a pain in the rear to scale it.

Also let's eliminate traffic and scaling from the picture. Take out setup. Now let's focus on use. What is your experience when using MySQL? How good are you with MySQL architecture and making efficient queries? How much time do you spend looking over queries with EXPLAIN? How much time do you spend making schema diagrams? ... I say take that time back. It's better spent elsewhere.

That's my two cents. I really do love MongoDB and hope to never use MySQL again and for the type of web sites I build, it's very possible that I won't need to. Though I'm still trying to find out WHEN I would want to use MySQL over MongoDB, not when I CAN (let's face it, it stores data, congratulations, I could write a ton of XML files too but it's not a good idea), but when it would BENEFIT to use one or the other. In the meantime, I'm going to go do my job with MongoDB and have less headaches.

Americanism

Answer 5

As long as you don't need multi-object transactions, MongoDB can be a favorable replacement for an RDMBS, especially in a web application context. Speed, schemalessness, and document modeling are all helpful this domain.

Awake

Answer 6

In my opinion document-oriented databases are only good for

1. Databases which data is better represented using a hierarchical (tree) model. This is not common for website databases.
2. Databases with huge amount of data like the Facebook and Amazon databases. In this case it is required to sacrifice the benefits of the relational model.

Door

Answer 7

MongoDB main characteristics are

• document model (JSON)
  high level(close to real world object), less collections
• sharding (optional)
• programmer friendly
  drivers, same data structures arrays/hash maps

Document databases
A document is more general than a table, its far easier to represent a table with a JSON than storing JSON to a table.
So yes document databases could replace table databases.

Sharding
Joins in sharded collections are expensive for any database. MongoDB added $lookup years now, and in MongoDB 5.1+ it can be used even when both collections are sharded.
But looks like joins in distributed databases are slow, and should be avoided, so relational way of modelling should be avoided.

No sharding
I think when sharding isn't used, MongoDB will co-exists and overlap with relational databases(especially after ACID support and $lookup support), to replace them its hard, and doesn't look like goal of MongoDB right now.

So overal looks like MongoDB could do what relational databases do, but for now its not a replacement. The opposite isn't true, relational databases have much bigger problems if they try to behave like MongoDB

Confinement

Answer 8

AFAIK, document databases don't have JOIN. That's pretty much a show-stopper for > 99% of data management needs.

As Matthew Flaschen points out in the comments, even on the desktop, databases such as SQLite are introducing SQL semantics to areas that have traditionally used propriety file formats or XML.

Ora

That would mean that today only less than 1% of the data isn't stored and managed in an rdbms? However a lot of data is stored in spreadsheets, the file system, logfiles, word documents and pfd files. I think Google Earth doesn't use an rdbms either. Do you store your holiday pictures in an rdbms? I don't, I store them on the file system and I manage them with picasa. Rdbms's are especially used for stuff that is somehow related to money. – Nodababus

Fair point, Theo. I was thinking primarily of business data centers, not the desktop. – Ora

Document databases use different modeling strategies; for instance, you can easily run and entire site on MongoDB without a single join. Lack of joins is hardly a show-stopper. – Awake

@Theo, Picasa uses a relational database (mail-archive.com/[email protected]/msg49389.html). – Lebaron

@kb, certain special kinds of application are amenable to document databases. That doesn't mean that document databases are going to take over the world. Much of the work I do requires very complex queries involving joins across many tables and would be utterly impossible to express in a document database. – Ora

In my train ride home I thought that I could have made a mistake by using Picasa as an example. However Google Earth doesn't store its data on the desktop so it's not a "desktop" only thing. I do use sqlite but without joins so I have contemplated about replacing it with an embedded document store or a key-value-store. – Nodababus

@Marcelo, not doubt, there are cases where you absolutely need SQL and joins. But there are also plenty of cases where a document database with map-reduce aggregation is, in the end, more worthwhile. I'm mostly speaking of the average web application and not data warehousing / complex data analysis. – Awake

@kb, I worked on an "average" (whatever that means) web application at my last job. It had a data model comprimising dozens of tables and almost every query in the system had joins, many of them comprising half a dozen tables or more. Any reasonable-size project that manages data of even modest complexity cannot possibly get by without joins. It is naïve to think otherwise. – Ora