面向文档的数据库是否意味着取代关系数据库？

Question

最近我和MongoDB一直在合作，我不得不说我非常喜欢它。然而，它是一个完全不同类型的数据库然后我被使用。我注意到它对于某些类型的数据肯定更好，但对于规范化程度很高的数据库，它可能不是最佳选择。

但在我看来，它可以完全取代你可能拥有的任何关系数据库，并且在大多数情况下表现更好，这令人难以置信。这让我想问几个问题：

1. 正在开发面向文档的数据库是下一代数据库，并且基本上完全取代了关系数据库吗？
2. 项目是否可能更好地同时使用面向文档的数据库和关系数据库来获取更适合其中一种的各种数据？
3. 如果面向文档的数据库不是要取代关系数据库，那么有没有人有一个数据库结构的例子，这在关系数据库中绝对会更好（反之亦然）？

Answer 1

  

面向文档的数据库是否已经发展成为下一代数据库并且基本上完全取代了关系数据库？

没有。面向文档的数据库（如MongoDB）非常擅长我们通常在现代网站中看到的任务类型（快速查找单个项目或小组项目）。

但他们与关系系统进行了一些重大的权衡。如果没有ACID合规性，他们将无法取代某些RDBMS。如果你看一下像MongoDB这样的系统，缺乏ACID合规性是一个很快的原因。

  

对于各种更适合其中一种数据的数据，是否可能更好地同时使用面向文档的数据库和关系数据库？

是。事实上，我正在运行一个使用两者的非常大的生产网站。该系统是在MySQL中启动的，但是我们将部分内容迁移到了MongoDB，b / c我们需要一个Key-Value存储，而MySQL在150M记录中找不到一个项目并不是很好。

  

如果面向文档的数据库不是要替换关系数据库，那么是否有人有一个数据库结构的例子，这在关系数据库中绝对会更好（反之亦然）？

面向文档的数据库非常适合存储数据，这些数据很容易包含在“键值”和简单的线性“父子”关系中。这里的简单示例包括Blogs和Wikis。

然而，关系型数据库仍然在报告等方面有很强的优势，这往往是“基于设置的”。

老实说，我可以看到一个世界，其中大多数数据由面向文档的数据库“处理”，但报告是在由Map-reduce作业更新的关系数据库中完成的。

Answer 2

这实际上是一个适合目的的问题。

如果您希望能够将某些表连接在一起并返回一组经过筛选的结果，则只能使用关系数据库执行此操作。如果您想要令人惊叹的性能并且拥有大量数据，那就是当列族或面向文档的数据库出现时。

这是一个经典的权衡。关系数据库为您提供了一整套功能，并带来了性能成本。如果您无法加入，索引，扫描或执行其他功能列表，则无需对所有数据进行任何查看，从而为您提供了处理严重数据所需的性能和分布。

另外，我建议您关注Ayende Rahien的博客。

http://ayende.com/blog/

Answer 3

@Sohnee是现货。我可能会添加关系数据库

• 非常适合以意想不到的组合方式检索信息 - 即使偶尔会导致在时间敏感的生产系统而不是单独的数据仓库上运行大量报告的错误想法。
• 是一种成熟的技术，您可以轻松地找到任意数量问题的人员和经过良好测试的解决方案（包括关系模型的局限性，以及SQL的不完善实现）。

问问自己你想做什么，品质对你很重要。您可以在shell脚本中执行所有与编程相关的操作你想要_____吗？

Answer 4

我一直在问同样的问题，这就是让我来到这里的原因。我同时使用MySQL和MongoDB（目前不是串联，虽然它的想法）。我必须诚实地说，我很高兴永远不再触摸MySQL。当然有“ACID”合规性，但您是否曾经遇到过使用MySQL修复表格的需求？你有没有损坏的数据库？它发生了。你有没有与MySQL有任何其他问题？任何锁定争用或死锁？集群有什么问题吗？设置和配置有多容易？

MongoDB ......你打开它就完成了......然后就是自动进行攻击。它非常简单，速度也非常快。所以考虑一下。你的时间。

不，他们没有JOIN，但这是一个完全错误的陈述，说它折扣超过99％的数据管理需求。在尝试解释MongoDB时，我常常反对，人们甚至在窃笑。我们只是面对它。人们不想学习新事物，他们认为他们所知道的就是他们所需要的。当然，你可以在余生中使用MySQL，并建立自己的网站。它有效，我们知道它有效。我们也知道它失败了。如果没有，你永远不会问这个问题，我们可能不会看到这么多面向文档的数据库。我们知道是的，它确实可以扩展，但后面的扩展是一种痛苦。

另外，让我们从图片中消除流量和缩放。取出设置。现在让我们专注于使用。使用MySQL时有什么经验？ MySQL架构和高效查询有多好？您花了多少时间查看EXPLAIN查询？你花了多少时间制作架构图？ ......我说那个时间回来了。最好在其他地方度过。

那是我的两分钱。我真的很喜欢MongoDB，并希望永远不再使用MySQL，对于我构建的网站类型，我很可能不需要。虽然我仍然试图找出什么时候我想要在MongoDB上使用MySQL，但不是在我可以（让我们面对它，它存储数据，恭喜，我也可以编写大量的XML文件，但这不是一个好主意） ，但是当它使用一个或另一个时会受益。与此同时，我将继续使用MongoDB工作，并且不会感到头疼。

Answer 5

只要您不需要多对象事务，MongoDB就可以成为RDMBS的有利替代品，尤其是在Web应用程序环境中。速度，无模式和文档建模在这个领域都很有用。

Answer 6

在我看来，面向文档的数据库只适用于

1. 使用分层（树）模型更好地表示数据的数据库。这对于网站数据库来说并不常见。
2. 拥有大量数据的数据库，如Facebook和亚马逊数据库。在这种情况下，需要牺牲关系模型的好处。

Answer 7

AFAIK，文档数据库没有JOIN。这几乎是＆gt; 99％的数据管理需求。

正如Matthew Flaschen在评论中指出的那样，即使在桌面上，SQLite等数据库也会将SQL语义引入传统上使用专有文件格式或XML的领域。