我们提供了一个用于视频和音频剪辑，照片和矢量图像的平台。我们从MySQL作为数据库后端开始，最近加入了MongoDB来存储文件的所有元信息，因为MongoDB更适合要求。例如：照片可能具有Exif信息，视频也可能具有音轨，我们也想在其中存储元信息。视频和矢量图形不共享任何通用的元信息，等等。因此，我知道MongoDB非常适合存储这种非结构化数据并保持其可搜索性。
但是，我们将继续开发平台并添加功能。现在，下一步就是为我们的用户提供一个论坛。现在出现的问题是：使用MySQL数据库，这将是存储论坛和论坛帖子等的不错选择，还是为此使用MongoDB？
所以问题是：何时使用MongoDB以及何时使用RDBMS。如果可以选择的话，您会选择mongoDB还是MySQL？为什么选择它？
在NoSQL中：如果就这么简单，作者将写有关MongoDB的文章：
MongoDB不是键/值存储，它还有很多。绝对不是RDBMS。我没有在生产中使用过MongoDB，但我在构建测试应用程序时就使用了它，这是一个非常酷的工具包。它似乎非常有效，并且具有或将很快具有容错能力和自动分片功能（也可以扩展）。我认为，Mongo可能是迄今为止我所见过的最接近RDBMS替代品的产品。它不适用于所有数据集和访问模式，但它是为典型的CRUD设计的。大多数人使用关系数据库来存储本质上是一个巨大的哈希，并能够在任何这些键上进行选择。 如果您的数据库是3NF，并且您不执行任何联接（您只是选择一堆表并将所有对象放在一起，这就是大多数人在Web应用程序中所做的事情），那么MongoDB可能会为您踢屁股。
然后，在结论中：
真正要指出的是，如果由于无法选择数据库而使您无法制作超棒的东西，那说明您做错了。 如果您知道mysql，请使用它。在实际需要时进行优化。像ak / v商店一样使用它，像rdbms一样使用它，但是出于上帝的缘故，构建您的杀手级应用程序！这与大多数应用无关。Facebook仍然大量使用MySQL。维基百科经常使用MySQL。FriendFeed大量使用MySQL。 NoSQL是一个很棒的工具，但是它肯定不会成为您的竞争优势，也不会使您的应用程序变得炙手可热，最重要的是，您的用户不会在意这些。 我要如何构建下一个应用程序？大概是Postgres。我会使用NoSQL吗？也许。我可能还会使用Hadoop和Hive。我可能会将所有内容保存在平面文件中。也许我会开始在Maglev上进行黑客攻击。 我将使用最适合该工作的东西。 如果我需要报告，则不会使用任何NoSQL。 如果需要缓存，则可能会使用Tokyo Tyrant。 如果需要ACIDity，则不会使用NoSQL。 如果我需要大量的计数器，我将使用Redis。 如果我需要交易，我将使用Postgres。 如果我有大量的单一类型的文档，则可能会使用Mongo。 如果我每天需要编写10亿个对象，则可能会使用Voldemort。如果我需要全文搜索，则可能会使用Solr。如果我需要对易失性数据进行全文搜索，则可能会使用Sphinx。
真正要指出的是，如果由于无法选择数据库而使您无法制作超棒的东西，那说明您做错了。 如果您知道mysql，请使用它。在实际需要时进行优化。像ak / v商店一样使用它，像rdbms一样使用它，但是出于上帝的缘故，构建您的杀手级应用程序！这与大多数应用无关。Facebook仍然大量使用MySQL。维基百科经常使用MySQL。FriendFeed大量使用MySQL。 NoSQL是一个很棒的工具，但是它肯定不会成为您的竞争优势，也不会使您的应用程序变得炙手可热，最重要的是，您的用户不会在意这些。
我要如何构建下一个应用程序？大概是Postgres。我会使用NoSQL吗？也许。我可能还会使用Hadoop和Hive。我可能会将所有内容保存在平面文件中。也许我会开始在Maglev上进行黑客攻击。 我将使用最适合该工作的东西。 如果我需要报告，则不会使用任何NoSQL。 如果需要缓存，则可能会使用Tokyo Tyrant。 如果需要ACIDity，则不会使用NoSQL。 如果我需要大量的计数器，我将使用Redis。 如果我需要交易，我将使用Postgres。 如果我有大量的单一类型的文档，则可能会使用Mongo。 如果我每天需要编写10亿个对象，则可能会使用Voldemort。如果我需要全文搜索，则可能会使用Solr。如果我需要对易失性数据进行全文搜索，则可能会使用Sphinx。
我喜欢这篇文章，我发现它非常有用，它很好地概述了NoSQL的概况和炒作。但是，那是最重要的部分，它确实有助于在RDBMS和NoSQL之间进行选择时问自己正确的问题。值得一读的恕我直言。
