我们为视频和音频剪辑、照片和矢量图提供平台。我们从 MySQL 作为数据库后端开始，最近包括MongoDB来存储文件的所有元信息，因为 MongoDB 更适合需求。例如：照片可能有Exif信息，视频可能有音轨，我们也想在其中存储元信息。视频和矢量图不共享任何共同的元信息等，所以我知道，MongoDB 非常适合存储这些非结构化数据并使其可搜索。
但是，我们会继续开发我们的平台并添加功能。现在接下来的步骤之一就是为我们的用户提供一个论坛。现在出现的问题是：使用 MySQL 数据库，这将是存储论坛和论坛帖子等的一个不错的选择，还是使用 MongoDB 呢？
所以问题是：何时使用 MongoDB，何时使用 RDBMS。如果您可以选择，您会选择 mongoDB 还是 MySQL，为什么要选择它？
在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 之间进行选择时，问自己正确的问题确实很有帮助。值得一读恕我直言。
在将 MongoDb 用于社交应用程序两年后，我见证了没有 SQL RDBMS 的真正意义。
我相信 98% 的项目使用典型的 SQL RDBMS 可能比使用 NoSQL 好得多。
存储这些非结构化数据
正如您所说，MongoDB 最适合存储非结构化数据。这可以将您的数据组织成文档格式。这些 RDBMS 替代品称为NoSQL数据存储（MongoDB、CouchDB、Voldemort）对于大规模扩展并需要从这些大数据存储中更快地访问数据的应用程序非常有用。
并且这些数据库的实现比常规的 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 的两个主要原因是
它适用于大数据应用。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！