28

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

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

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

7 回答 7

36

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

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

但是他们在关系系统上做了一些重大的权衡。如果没有 ACID 合规性之类的东西，他们将无法替代某些 RDBMS。如果你看看像 MongoDB 这样的系统，缺乏 ACID 合规性是它如此之快的一个重要原因。

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

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

如果面向文档的数据库不打算取代关系数据库，那么有没有人有一个数据库结构的例子，在关系数据库中绝对会更好（反之亦然）？

面向文档的数据库非常适合存储很容易包含在“键值”和简单的线性“父子”关系中的数据。这里的简单示例是博客和 Wiki 之类的东西。

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

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

于 2010-05-24T07:09:52.283 回答
5

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

如果您希望能够将一些表连接在一起并返回一组过滤的结果，您只能使用关系数据库来实现。如果您想要令人难以置信的性能并拥有令人难以置信的数据量，那么列族或面向文档的数据库就应运而生了。

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

另外，我建议您关注 Ayende Rahien 关于此主题的博客。

http://ayende.com/blog/

于 2010-05-19T14:07:49.860 回答
2

@Sohnee 很到位。我可能会添加关系数据库

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

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

于 2010-05-19T14:17:39.957 回答
1

我一直在问同样的问题，这就是我来到这里的原因。我同时使用 MySQL 和 MongoDB（目前没有同时使用，尽管这是一个想法）。老实说，我很高兴再也不会碰 MySQL。当然有“ACID”合规性，但是您是否曾经遇到过使用 MySQL 修复表的需要？你有过损坏的数据库吗？它发生了。你在使用 MySQL 时遇到过其他问题吗？任何锁争用或死锁？集群有什么问题吗？设置和配置有多容易？

MongoDB……你打开它就完成了……然后它是自动分片。它非常简单，而且速度也非常快。所以想想吧。您的时间。

不，他们没有 JOIN，但说它降低了 99% 以上的数据管理需求是完全错误的说法。当我试图解释 MongoDB 时，我经常遭到反对，人们甚至窃笑。让我们面对它。人们不想学习新事物，他们认为他们所知道的就是他们所需要的。当然，您可以在余生中使用 MySQL 并构建您的网站。它有效，我们知道它有效。我们也知道它失败了。如果没有，你永远不会问这个问题，我们可能不会看到这么多面向文档的数据库。我们知道是的，它确实可以扩展，但是扩展它是一件很痛苦的事情。

另外，让我们从图片中消除流量和缩放。取出设置。现在让我们专注于使用。您在使用 MySQL 时的体验如何？您在 MySQL 架构和高效查询方面的表现如何？你花多少时间用 EXPLAIN 查看查询？你花多少时间制作模式图？......我说把那个时间带回去。最好花在别处。

那是我的两分钱。我真的很喜欢 MongoDB，并希望永远不要再使用 MySQL，对于我构建的网站类型，我很有可能不需要。尽管我仍在尝试找出何时我想在 MongoDB 上使用 MySQL，而不是何时可以（让我们面对现实吧，它存储数据，恭喜，我也可以编写大量 XML 文件，但这不是一个好主意） ，但是什么时候使用其中一种会是有益的。与此同时，我将继续使用 MongoDB 完成我的工作，并减少头痛。

于 2010-07-29T04:32:25.577 回答
0

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

于 2010-05-20T02:09:47.220 回答
0

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

  1. 使用分层（树）模型更好地表示哪些数据的数据库。这对于网站数据库并不常见。
  2. 拥有大量数据的数据库，例如 Facebook 和 Amazon 数据库。在这种情况下，需要牺牲关系模型的好处。
于 2011-11-25T21:03:24.817 回答
-2

AFAIK，文档数据库没有 JOIN。这几乎可以满足 99% 以上的数据管理需求。

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

于 2010-05-19T14:05:50.620 回答