何时使用 MongoDB 或其他面向文档的数据库系统？ [关闭]

在 NoSQL: If Only It Was That Easy 中，作者写到了 MongoDB：

MongoDB 不是键/值存储，它更多。它也绝对不是 RDBMS。我没有在生产中使用过 MongoDB，但我已经用它构建了一个测试应用程序，它是一个非常酷的工具包。它似乎非常高效，并且已经或即将拥有容错和自动分片（也就是它会扩展）。我认为 Mongo 可能是迄今为止我见过的最接近 RDBMS 替代品的东西。它不适用于所有数据集和访问模式，但它是为典型的 CRUD 内容而构建的。存储本质上是一个巨大的散列，并能够选择任何这些键，是大多数人使用关系数据库的目的。如果您的数据库是 3NF 并且您不进行任何连接（您只是选择一堆表并将所有对象放在一起，也就是大多数人在 Web 应用程序中所做的），MongoDB 可能会为您提供帮助。

然后，在结论中：

真正要指出的是，如果你因为无法选择数据库而无法做出超级棒的东西，那你就做错了。如果你知道mysql，就用它。在您真正需要时进行优化。像 ak/v 商店一样使用它，像 rdbms 一样使用它，但是看在上帝的份上，构建你的杀手级应用！这对大多数应用程序都无关紧要。 Facebook 仍然大量使用 MySQL。 Wikipedia 大量使用 MySQL。 FriendFeed 经常使用 MySQL。 NoSQL 是一个很棒的工具，但它肯定不会成为你的竞争优势，它不会让你的应用程序变得热门，而且最重要的是，你的用户不会关心这些。我将在什么基础上构建下一个应用程序？可能是Postgres。我会使用 NoSQL 吗？也许。我也可能使用 Hadoop 和 Hive。我可能会将所有内容保存在平面文件中。也许我会开始在 Maglev 上进行黑客攻击。我会使用最适合这项工作的东西。如果我需要报告，我不会使用任何 NoSQL。如果需要缓存，我可能会使用 Tokyo Tyrant。如果我需要 ACIDity，我不会使用 NoSQL。如果我需要大量的计数器，我会使用 Redis。如果我需要交易，我会使用 Postgres。如果我有大量单一类型的文档，我可能会使用 Mongo。如果我需要每天编写 10 亿个对象，我可能会使用 Voldemort。如果我需要全文搜索，我可能会使用 Solr。如果我需要对易失性数据进行全文搜索，我可能会使用 Sphinx。

我喜欢这篇文章，我觉得它信息量很大，它很好地概述了 NoSQL 的前景和炒作。但是，这是最重要的部分，在 RDBMS 和 NoSQL 之间进行选择时，问自己正确的问题确实很有帮助。值得一读恕我直言。

Alternate link to article

在将 MongoDb 用于社交应用程序两年后，我见证了没有 SQL RDBMS 的真正意义。

您最终会编写作业来完成诸如连接来自不同表/集合的数据之类的事情，这是 RDBMS 会自动为您完成的事情。您使用 NoSQL 的查询能力被严重削弱。 MongoDb 可能是最接近 SQL 的东西，但仍然远远落后。相信我。 SQL 查询超级直观、灵活且功能强大。 MongoDb 查询不是。 MongoDb 查询只能从一个集合中检索数据，并且只能利用一个索引。 MongoDb 可能是最灵活的 NoSQL 数据库之一。在许多情况下，这意味着更多往返于服务器以查找相关记录。然后你开始去规范化数据——这意味着后台作业。它不是关系数据库这一事实意味着您不会（被某些人认为表现不佳）外键约束来确保您的数据是一致的。我向您保证，这最终会在您的数据库中造成数据不一致。做好准备。您很可能会开始编写流程或检查以保持数据库的一致性，这可能不会比让 RDBMS 为您执行更好。忘记像hibernate这样的成熟框架。

我相信 98% 的项目使用典型的 SQL RDBMS 可能比使用 NoSQL 好得多。

存储这些非结构化数据

正如您所说，MongoDB 最适合存储非结构化数据。这可以将您的数据组织成文档格式。这些称为 NoSQL 数据存储（MongoDB、CouchDB、Voldemort）的 RDBMS 替代方案对于大规模扩展并需要从这些大数据存储中更快地访问数据的应用程序非常有用。

并且这些数据库的实现比常规的 RDBMS 更简单。由于这些是直接序列化到磁盘中的简单键值或文档样式的二进制对象。这些数据存储不强制执行 ACID 属性和任何模式。这不提供任何交易能力。所以这可以扩大规模，我们可以实现更快的访问（读取和写入）。

但相比之下，RDBM 对数据强制执行 ACID 和模式。如果您想使用结构化数据，您可以继续使用 RDBM。

我会选择 MySQL 来为这类东西创建论坛。因为这不会扩大规模。这是一个非常简单（常见）的应用程序，它在数据之间具有结构化的关系。

请注意，Mongo 本质上存储 JSON。如果您的应用程序正在处理大量 JS 对象（带有嵌套）并且您想要持久化这些对象，那么使用 Mongo 有一个非常强大的论据。它使您的 DAL 和 MVC 层超薄，因为它们没有解包所有 JS 对象属性并试图将它们强制适合它们不自然适合的结构（模式）。

我们有一个系统，其核心包含几个复杂的 JS 对象，我们喜欢 Mongo，因为我们可以非常非常轻松地持久化所有内容。我们的对象也是相当无定形和非结构化的，Mongo 毫不犹豫地吸收了这种复杂性。我们有一个自定义报告层，可以破译人类消费的无定形数据，这并不难开发。

谁需要分布式的分片论坛？也许是 Facebook，但除非你正在创建一个 Facebook 竞争对手，否则只需使用 Mysql、Postgres 或任何你最喜欢的东西。如果您想尝试 MongoDB，可以，但不要指望它会为您带来魔力。它会有它的怪癖和一般的肮脏，就像其他一切一样，我相信你已经发现了，如果你真的已经在研究它了。

当然，MongoDB 可能被大肆宣传，表面上看起来很容易，但您会遇到更成熟的产品已经克服的问题。不要那么容易被引诱，而是等到“nosql”成熟，或者死亡。

就个人而言，我认为“nosql”会因碎片化而枯萎和消亡，因为没有固定的标准（几乎按照定义）。所以我个人不会为任何长期项目打赌。

在我的书中，唯一可以节省“nosql”的是它是否可以无缝集成到 Ruby 或类似语言中，并使语言“持久化”，几乎没有任何编码和设计开销。这可能会实现，但我会等到那时，而不是现在，当然它需要更加成熟。

顺便说一句，您为什么要从头开始创建论坛？有大量的开源论坛可以进行调整以满足大多数需求，除非你真的在创建下一代论坛（我对此表示怀疑）。

如果您需要复杂的事务，我会说使用 RDBMS。否则我会选择 MongoDB——使用起来更灵活，而且你知道它可以在你需要的时候进行扩展。 （虽然我有偏见 - 我在 MongoDB 项目上工作）

您可能想要更喜欢 Mongo 的两个主要原因是

架构设计的灵活性（JSON 类型的文档存储）。

可扩展性 - 只需添加节点，它就可以很好地水平扩展。

它适用于大数据应用。 RDBMS 不适合大数据。

我看到很多公司都在使用 MongoDB 从应用程序日志中进行实时分析。它的无模式确实适合应用程序日志，其中记录模式往往会不时更改。此外，它的 Capped Collection 功能很有用，因为它会自动清除旧数据以保持数据适合内存。

这是我真正认为 MongoDB 适合的一个领域，但通常更推荐 MySQL/PostgreSQL。网络上有很多文档和开发人员资源，以及它们的功能和健壮性。

你知道，关于连接和“复杂事务”的所有这些东西——但多年前，正是蒙蒂本人解释了 COMMIT / ROLLBACK 的“需要”，并说“所有这些都在逻辑类中完成” （而不是数据库）无论如何' - 所以这又是同一件事。需要一个笨拙但非常整洁和快速的数据存储/检索引擎，用于 99% 的 Web 应用程序所做的工作。

如前所述，您可以在很多选项中进行选择，看看所有这些选项：http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

我的建议是找到你的最佳组合：如果你需要 ACID 并且你想加入一些表，MySQL + Memcache 真的很棒 MongoDB + Redis 非常适合文档存储 Neo4J 非常适合图形数据库

我做什么：我从 MySQl + Memcache 开始，因为我习惯了，然后我开始使用其他数据库框架。例如，在一个项目中，您可以结合 MySQL 和 MongoDB！