面向文档的数据库是否会取代关系数据库？
最近我一直在使用 MongoDB，我不得不说我真的很喜欢它。然而，它是一种与我使用的完全不同类型的数据库。我注意到，对于某些类型的数据来说，它绝对更好，但是对于高度规范化的数据库来说，它可能不是最佳选择。
然而，在我看来，它可以完全取代您可能拥有的任何关系数据库，并且在大多数情况下性能更好，这是令人难以置信的。这让我问几个问题：
- 面向文档的数据库是否正在被开发为下一代数据库并基本上完全取代关系数据库？
- 项目是否可能同时使用面向文档的数据库和关系数据库来处理更适合其中一种或另一种的各种数据？
- 如果面向文档的数据库并不是要取代关系数据库，那么是否有人有一个在关系数据库中绝对更好的数据库结构示例（反之亦然）？
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:
- Are document-oriented databases being developed to be the next generation of databases and basically replace relational databases completely?
- 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?
- 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)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
不会。面向文档的数据库（例如 MongoDB）非常适合我们在现代网站中常见的任务类型（快速查找单个项目或一小组项目）。
但他们对关系系统做出了一些重大的权衡。如果没有诸如 ACID 合规性之类的东西，它们将无法取代某些 RDBMS。如果你看看 MongoDB 这样的系统，就会发现缺乏 ACID 合规性是它如此之快的一个重要原因。
是的。事实上，我正在运行一个使用两者的非常大的生产网站。该系统是在 MySQL 中启动的，但我们已将其部分迁移到 MongoDB，因为我们需要一个键值存储，而 MySQL 不太擅长在 150M 记录中查找一项。
面向文档的数据库非常适合存储易于包含在“键值”和简单的线性“父子”关系中的数据。这里的简单例子是博客和维基。
然而，关系数据库在报告等方面仍然具有强大的优势，因为报告往往是“基于集合的”。
老实说，我可以看到这样一个世界：大多数数据都是由面向文档的数据库“处理”的，但报告是在由 Map-reduce 作业更新的关系数据库中完成的。
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.
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.
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.
这实际上是一个是否适合目标的问题。
如果您希望能够将一些表连接在一起并返回一组经过过滤的结果，则只能使用关系数据库来实现。如果您想要令人难以置信的性能并且拥有令人难以置信的数据量，那么列族或面向文档的数据库就可以派上用场。
这是一个经典的权衡。关系数据库为您提供了一整套功能，但会带来性能成本。如果您无法加入、索引、扫描或执行整个其他功能列表，则无需查看所有数据，这将为您提供处理重要数据所需的性能和分布。
另外，我建议您关注 Ayende Rahien 关于此主题的博客。
http://ayende.com/blog/
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/
@Sohnee 说得对。我可能会补充一点，关系数据库
问问自己你想做什么，以及什么品质对你来说很重要。您可以在 shell 脚本中执行与编程相关的所有操作。你想要_____吗？
@Sohnee is spot on. I might add that relational databases
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?
我一直在问同样的问题，这就是我来到这里的原因。我同时使用 MySQL 和 MongoDB（目前没有同时使用，尽管这是一个想法）。老实说，我很高兴再也没有碰过 MySQL。当然有“ACID”合规性，但是您是否遇到过需要使用 MySQL 修复表的情况？您是否遇到过数据库损坏的情况？它发生了。您还遇到过 MySQL 的其他问题吗？是否存在锁争用或死锁？聚类有什么问题吗？设置和配置有多容易？
MongoDB...你打开它就完成了...然后就是自动分片。它非常简单，而且速度也非常快。所以想一想。你的时间。
不，他们没有 JOIN，但说它折扣了超过 99% 的数据管理需求，这是完全错误的说法。当我试图解释 MongoDB 时，经常遭到反对，人们甚至在窃笑。让我们面对现实吧。人们不想学习新事物，他们认为他们所知道的就是他们所需要的。当然，您可以在余生中使用 MySQL 来构建您的网站。它有效，我们知道它有效。我们也知道它失败了。如果没有，您就永远不会问这个问题，我们可能也不会看到这么多面向文档的数据库。我们知道它确实可以扩展，但是扩展它是一件痛苦的事。
另外，让我们消除图片中的流量和缩放。取出设置。现在让我们重点关注使用。使用MySQL有什么体验？您对 MySQL 架构和高效查询的掌握程度如何？您花费多少时间使用 EXPLAIN 查看查询？您花费多少时间制作架构图？ ......我说把那段时间收回来。最好花在其他地方。
这是我的两分钱。我真的很喜欢 MongoDB，并希望永远不再使用 MySQL，对于我构建的网站类型，我很可能不需要。虽然我仍在试图找出什么时候我想使用 MySQL 而不是 MongoDB，而不是什么时候我可以（让我们面对现实，它存储数据，恭喜，我也可以编写大量 XML 文件，但这不是一个好主意） ，但何时使用其中之一会有利。与此同时，我将用 MongoDB 来完成我的工作，这样就不会那么麻烦了。
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.
只要您不需要多对象事务，MongoDB 就可以成为 RDMBS 的理想替代品，尤其是在 Web 应用程序环境中。速度、无模式和文档建模对于这个领域都有帮助。
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.
在我看来，面向文档的数据库仅适用于
In my opinion document-oriented databases are only good for
MongoDB主要特点是
高水平（接近现实世界对象），较少的集合
驱动程序，相同的数据结构数组/哈希映射
文档数据库
文档比表格更通用，用 JSON 表示表格比将 JSON 存储到表格要容易得多。
所以文档数据库可以取代表数据库。
分片
对于任何数据库来说，分片集合中的连接都是昂贵的。
MongoDB 添加了
$lookup几年了，在 MongoDB 5.1+ 中，即使两个集合都分片也可以使用它。但看起来分布式数据库中的连接速度很慢，应该避免，因此应该避免关系建模方式。
无分片
我认为当不使用分片时，MongoDB将与关系数据库共存并重叠（特别是在ACID支持和$lookup支持之后），取代它们很困难，而且看起来不像MongoDB现在的目标。
总的来说，MongoDB 可以做关系数据库做的事情，
但目前它还不能替代。
相反的情况则不然，如果关系数据库试图表现得像 MongoDB，则会出现更大的问题
MongoDB main characteristics are
high level(close to real world object), less collections
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
$lookupyears 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
AFAIK，文档数据库没有 JOIN。对于>来说，这几乎是一个令人惊叹的表演。 99% 的数据管理需求。
正如 Matthew Flaschen 在评论中指出的那样，即使在桌面上，SQLite 等数据库也在向传统上使用专有文件格式或 XML 的领域引入 SQL 语义。
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.