何时使用 MongoDB [关闭]

Posted 2023-02-16

【中文标题】何时使用 MongoDB [关闭]

【英文标题】：When to use MongoDB [closed]

【发布时间】：2011-06-26 06:55:48

【问题描述】：

我正在编写一个不一定需要扩展能力的应用程序，因为它一开始不会收集大量数据。 （但是，如果我幸运的话，我可能会走上这条路。）

我将在同一个机器上运行我的网络服务器和数据库（目前）。

话虽如此，我正在寻找性能和效率。

我的应用程序的主要部分是加载博客文章。使用 RDBMS (mysql) 我将进行 6 个查询（其中 2 个查询是连接的），只是为了加载一个博客文章页面。

select blog
select blog_album
select blog_tags
select blog_notes
select blog_comments (join with users)
select blog_author_participants (join with users)

但是，使用MongoDB，我可以将 6 个表反规范化并展平为 2 个表/集合，并将我的查询最小化为可能只有 1 个查询，

users
blogs
    ->blog_album
    ->blog_tags        
    ->blog_notes
    ->blog_comments
    ->blog_author_participants

现在，使用 MongoDB 架构，会有一些数据冗余。但是，硬盘空间比 CPU/服务器便宜。

1.) 这是使用 MongoDB 的好场景吗？

2.) 使用 MongoDB 进行扩展时，您是否只会在性能方面受益？

3.) 使用 MongoDB 是否存在任何持久性风险？我听说在执行插入时可能会丢失数据 - 因为插入首先写入内存，然后写入数据库。

4.) 这是否应该阻止我在生产中使用 MongoDB？

【问题讨论】：

"我正在寻找性能和效率。"和“我将在同一个盒子上运行我的网络服务器和数据库。”彼此矛盾。

3000 万人使用 WordPress 似乎做得很好，每页运行同样多的查询来显示他们的博客。您似乎已经被 NoSQL 炒作所吸引。当您实际上对 RDBMS 的查询过多而无法构建页面时遇到问题，您只需在前面扔一个缓存代理，或者更简单，在您的博客平台中一键安装缓存插件。

MongoDB is Web Scale

【参考方案1】：

NoSQL vs. RDBMS: Apples and Oranges?

我建议您在决定是否可以使用 NoSQL 之前先阅读一下什么是 NoSQL 以及它的作用。你不能像这样把一个普通的数据库变成一个 NoSQL 的东西。您处理数据的方式完全不同。

NoSQL 肯定有它的用途。但这绝对不是所有问题的答案。 NoSQL 的主要优点是易于更改的数据模型。

【参考方案2】：

我不能谈论性能方面的考虑，但对我来说，要使用 SQL-DB 还是 MongoDB，首先要考虑的是要存储的数据的结构。

从某种意义上说，MongoDB 是“无模式”的，因为您不需要事先知道您想要什么“表”和“列”。它非常灵活。因此，如果您不知道要在“博客”集合中存储哪些信息，或者如果不同的博客文章可能存储不同的信息，那么 MongoDB 允许这种灵活性。而对于 SQL 关系数据库，您必须预先了解您的架构。

但听起来您已经知道要存储什么信息，在这种情况下，我可能会坚持使用 SQL 关系数据库。在您的情况下，我不认为性能是首要考虑因素 - 您不是在构建一个实时应用程序，其中一两毫秒非常重要。

【参考方案3】：

这里有一个很好的解释：http://mod.erni.st/nosql-if-only-it-was-that-easy/

最后一段总结：

我将在什么基础上构建下一个应用程序？可能是Postgres。我会使用 NoSQL 吗？可能是。我也可能使用 Hadoop 和 Hive。我可能会将所有内容保存在平面文件中。也许我会开始在 Maglev 上进行黑客攻击。我会使用最适合这项工作的东西。如果我需要报告，我不会使用任何 NoSQL。如果需要缓存，我可能会使用 Tokyo Tyrant。如果我需要 ACIDity，我不会使用 NoSQL。如果我需要大量的计数器，我会使用 Redis。如果我需要交易，我会使用 Postgres。如果我有大量单一类型的文档，我可能会使用 Mongo。如果我需要每天写 10 亿个对象，我可能会使用 Voldemort。如果我需要全文搜索，我可能会使用 Solr。如果我需要对易失性数据进行全文搜索，我可能会使用 Sphinx。

【讨论】：

等等，redis 是 NoSQL

【参考方案4】：

使用 mongodb 的优势（根据Moshe Kaplan 发表于dzonearticle）

无架构设计 管理 Tera 字节数据的可扩展性 具有高可用性功能的快速副本集 分片可实现线性和横向扩展，而不会超出预算 支持高写入负载 使用数据局部性进行查询处理

MongoDB 满足 CAP 理论中的 Consistency 和 Partitioning 要求（一致性、可用性和分区）

相关的 SE 问题：

What are the advantages of using a schema-free database like MongoDB compared to a relational database?

When to Redis? When to MongoDB?

【参考方案5】：

但是，使用 MongoDB，我可以将 6 个表反规范化并将其展平为仅 2 个表/集合，并将我的查询最小化为可能只有 1 个查询

但是您可以使用一条精心设计的 SQL 语句轻松地查询 MySQL 以获取与单个博客文章相关的 6 个表的信息。

但是硬盘空间比 CPU/服务器便宜。

如果性能和扩展是一个优先事项，那么您将关心有足够的 RAM 以将所有内容放入主内存中，以及有足够的 CPU 内核来运行查询。企业级 RAID 10 阵列是必需的，不要误会我的意思，但是一旦您的数据库软件（MongoDB 或 MySQL）需要扫描无法放入主内存的索引，您就会进入一个世界假设一个大型活动数据库的痛苦。 :)

我喜欢 MongoDB，但我认为它的强大之处在于 map/reduce 及其面向文档的功能。您不需要这些功能。 MySQL 在大规模部署中经过时间考验并支持分区（但我认为您的数据库必须在 50-100 GB 左右，然后才能从分区与单个（加上被动备份）服务器吨（64 GB+）的 RAM。我还认为，如果性能确实是一个问题，那么 MySQL 会更可取，因为您将对索引拥有最高的控制权。

这并不是说 MongoDB 的性能不高，但它的位置可能不是为博客服务。您对插入的关注也是有效的。 MongoDB 不是ACID 系统。两个系统中的 Google 交易并进行比较。

【参考方案6】：

当你有一个与其优势相匹配的用例时，你会使用 MongoDB。

您需要无模式文档存储吗？不，你有一个稳定的架构。

您需要自动分片吗？不，您没有非凡的数据需求或预算来横向扩展硬件。

您需要 map/reduce 数据处理吗？不适用于博客之类的东西。

那你为什么还要考虑呢？

【讨论】：

感谢您的回答，丹。我考虑使用 mongodb 的原因有 3 个：是的，mongodb 看起来确实很吸引人，在看到一些基准、教程、文章数量之后，我开始质疑，“为什么不使用 mongodb？” 1.）效率——减少查询次数，减少表数，维护代码。 2.) 它的灵活性——能够动态改变它的数据结构——但是，这种灵活性让我害怕冒着误写数据的风险

3：在过去的 7 年里，我一直在使用 mysql，我认为尝试一些新的东西会有好处。但是，话虽如此，如果在一台服务器上运行小型应用程序时 mongodb 对 mysql 没有任何好处......那么我看不出任何切换到 mongodb 的目的。谢谢你的回答。