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

Question

我们提供视频和音频剪辑，照片和矢量图的平台。我们从MySQL开始作为数据库后端，最近包括MongoDB用于存储文件的所有元信息，因为MongoDB更符合要求。例如：照片可能包含Exif个信息，视频也可能包含我们想要存储元信息的音轨。视频和矢量图形不共享任何常见的元信息，所以我知道，MongoDB非常适合存储这些非结构化数据并保持可搜索。

但是，我们会继续开发平台并添加功能。现在，接下来的步骤之一将是为我们的用户提供一个论坛。现在出现的问题是：使用MySQL数据库，这是存储论坛和论坛帖子等的好选择，或者也可以使用MongoDB吗？

所以问题是：何时使用MongoDB以及何时使用RDBMS。你会选择什么，mongoDB或MySQL，如果你有选择，你为什么要接受它？

Answer 1

在NoSQL: If Only It Was That Easy中，作者写了关于MongoDB的文章：

  

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

然后，在结论中：

  

值得注意的是，如果你因为无法选择数据库而无法制作超级棒的东西，那么你做错了。如果你知道mysql，只需要用它。在您确实需要时进行优化。像k / v商店一样使用它，像rdbms一样使用它，但为了上帝的缘故，建立你的杀手级应用程序！这些对大多数应用程序都不重要。 Facebook仍然使用MySQL，很多。维基百科使用MySQL，很多。 FriendFeed使用MySQL，很多。 NoSQL是一个很棒的工具，但它肯定不会成为你的竞争优势，它不会让你的应用程序变得热门，而且最重要的是，你的用户不会关心这些。 < / p>      

我打算构建下一个应用程序是什么？可能是Postgres。我会使用NoSQL吗？也许。我也可以使用Hadoop和Hive。我可能会把所有内容保存在平面文件也许我会开始攻击磁悬浮。 我将使用最适合这项工作的任何内容。 如果我需要报告，我将不会使用任何NoSQL。如果我需要缓存，我可能会使用东京暴君。 如果我需要ACIDity，我不会使用NoSQL。如果我需要大量的计数器，我会使用Redis。 如果我需要交易，我会使用Postgres。 如果我有大量单一类型的文档，我可能会使用Mongo。如果我需要写1每天有十亿件物品，我可能会使用Voldemort。如果我需要全文搜索，我可能会使用Solr。如果我需要对易失性数据进行全文搜索，我可能会使用Sphinx。

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

Alternate link to article

Answer 2

使用MongoDb作为社交应用程序两年后，我亲眼目睹了没有SQL RDBMS的真正意义。

1. 你最终写作业来做一些事情，比如从不同的表/集合中加入数据，这是RDBMS会自动为你做的事情。
2. 您对NoSQL的查询功能严重受损。 MongoDb可能是最接近SQL的东西，但它仍然远远落后于它。相信我。 SQL查询非常直观，灵活且功能强大。 MongoDb查询不是。
3. MongoDb查询只能从一个集合中检索数据，并且只能利用一个索引。 MongoDb可能是最灵活的NoSQL数据库之一。在许多情况下，这意味着更多往返服务器以查找相关记录。然后你开始对数据进行去规范化 - 这意味着后台工作。
4. 它不是关系数据库这一事实意味着您不会（通过某些人认为表现不佳）外键约束来确保您的数据是一致的。我向您保证，这最终会在您的数据库中创建数据不一致。做好准备。很可能你会开始编写进程或检查以保持数据库的一致性，这可能不会比让RDBMS为你做的更好。
5. 忘记像hibernate这样的成熟框架。

我相信，使用典型的SQL RDBMS，98％的项目可能比使用NoSQL更好。

Answer 3

  

存储此非结构化数据

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

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

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

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

Answer 4

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

我们的系统中有几个复杂的JS对象，我们喜欢Mongo，因为我们可以非常轻松地坚持一切。我们的对象也是非常无定形和非结构化的，而且Mongo在没有眨眼的情况下吸收并发症。我们有一个自定义报告层，可以解析人类消费的无定形数据，而且开发并不困难。

Answer 5

如果您需要复杂的交易，我会说使用RDBMS。否则我会使用MongoDB - 更灵活地使用它，你知道它可以在你需要时扩展。 （虽然我有偏见 - 我在MongoDB项目上工作）

Answer 6

谁需要分布式，分片论坛？也许Facebook，但除非你正在创建一个Facebook竞争对手，只需使用Mysql，Postgres或任何你最熟悉的东西。如果你想尝试MongoDB，好吧，但不要指望它为你做魔术。就像其他一切一样，它会有它的怪癖和一般的肮脏，因为我确信你已经发现了，如果你真的已经在研究它了。

当然，MongoDB可能会被炒作并且表面看起来很容易，但是你会遇到更成熟的产品已经克服的问题。不要那么容易被诱惑，而是等到“nosql”成熟或死亡。

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

只有可以在我的书中保存“nosql”的东西，如果它可以无缝地集成到Ruby或类似的语言中，并使语言“持久”，几乎没有编码和设计的任何开销。这可能会成真，但我会等到那时，而不是现在，当然它需要更加成熟。

顺便问一下，你为什么要从零开始创建一个论坛？有很多开源论坛可以调整以满足大多数要求，除非你真的在创建下一代论坛（我怀疑）。

Answer 7

我见过许多公司正在使用MongoDB从应用程序日志中进行实时分析。它的模式自由度非常适合应用程序日志，其中记录模式往往会随时更改。此外，它的Capped Collection功能很有用，因为它会自动清除旧数据，以使数据适合内存。

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

Answer 8

您可能希望选择Mongo的两个主要原因是

• 架构设计的灵活性（JSON类型文档存储）。
• 可扩展性 - 只需添加节点，它就可以很好地水平扩展。

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

Answer 9

你知道，关于连接和'复杂交易'的所有这些东西 - 但很多年前Monty本人解释了COMMIT / ROLLBACK的“需要”，并说'所有这些都是在无论如何，逻辑类（而不是数据库） - 所以它再次是同样的事情。我们需要的是一个愚蠢但非常整洁和快速的数据存储/检索引擎，占网络应用程序的99％。

Answer 10

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

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

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