在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
之间进行选择时，问自己正确的问题确实很有帮助。值得一读恕我直言。

文章的替代链接