我们为视频和音频剪辑、照片和矢量涂鸦提供了一个平台。我们从mysql作为数据库后端开始，最近包括了mongodb，用于存储文件的所有元信息，因为mongodb更好地满足了需求。例如：照片可能有exif信息，视频可能有音频轨，我们也希望在其中存储元信息。视频和矢量图形不共享任何常见的元信息等。所以我知道，MongoDB非常适合存储这些非结构化数据并保持其可搜索性。

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

所以问题是：什么时候使用MongoDB，什么时候使用RDBMS。如果你有选择的话，你会选择什么，MongoDB或者MySQL，为什么选择呢？

在nosql中：如果这么简单的话，作者写的是mongodb:

MongoDB is not a key/value store, it’s quite a bit more. It’s definitely not a RDBMS either. I haven’t used MongoDB in production, but I have used it a little building a test app and it is a very cool piece of kit. It seems to be very performant and either has, or will have soon, fault tolerance and auto-sharding (aka it will scale). I think Mongo might be the closest thing to a RDBMS replacement that I’ve seen so far. It won’t work for all data sets and access patterns, but it’s built for your typical CRUD stuff. Storing what is essentially a huge hash, and being able to select on any of those keys, is what most people use a relational database for. If your DB is 3NF and you don’t do any joins (you’re just selecting a bunch of tables and putting all the objects together, AKA what most people do in a web app), MongoDB would probably kick ass for you.

那么，在结论中：

The real thing to point out is that if you are being held back from making something super awesome because you can’t choose a database, you are doing it wrong. If you know mysql, just use it. Optimize when you actually need to. Use it like a k/v store, use it like a rdbms, but for god sake, build your killer app! None of this will matter to most apps. Facebook still uses MySQL, a lot. Wikipedia uses MySQL, a lot. FriendFeed uses MySQL, a lot. NoSQL is a great tool, but it’s certainly not going to be your competitive edge, it’s not going to make your app hot, and most of all, your users won’t care about any of this.

What am I going to build my next app on? Probably Postgres. Will I use NoSQL? Maybe. I might also use Hadoop and Hive. I might keep everything in flat files. Maybe I’ll start hacking on Maglev. I’ll use whatever is best for the job. If I need reporting, I won’t be using any NoSQL. If I need caching, I’ll probably use Tokyo Tyrant. If I need ACIDity, I won’t use NoSQL. If I need a ton of counters, I’ll use Redis. If I need transactions, I’ll use Postgres. If I have a ton of a single type of documents, I’ll probably use Mongo. If I need to write 1 billion objects a day, I’d probably use Voldemort. If I need full text search, I’d probably use Solr. If I need full text search of volatile data, I’d probably use Sphinx.

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

文章的备用链接

在使用MongoDB开发社交应用程序两年后，我见证了没有SQL RDBMS的生活真正意味着什么。

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

to store this unstructured data

如您所说，MongoDB最适合存储非结构化数据。这可以将您的数据组织成文档格式。这些称为nosql数据存储(mongodb、couchdb、voldemort)的RDBMS备选方案对于大规模扩展并要求从这些大数据存储更快地访问数据的应用程序非常有用。

这些数据库的实现比常规的RDBMS简单。因为这些是直接序列化到磁盘中的简单键值或文档样式的二进制对象。这些数据存储不强制使用ACID属性和任何模式。这不提供任何事务处理功能。因此，这可以扩大规模，我们可以实现更快的访问(读写)。

但是相反，RDBM在数据上强制使用ACID和模式。如果您想使用结构化数据，可以继续使用RDBM。

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

注意，Mongo基本上存储JSON。如果你的应用程序处理了很多JS对象(有嵌套)，并且你想要持久化这些对象，那么使用Mongo有一个非常有力的理由。它使DAL和MVC层变得非常薄，因为它们并没有将所有JS对象属性都解包，并试图强制将它们放入一个它们自然不适合的结构(模式)中。

我们有一个系统，它的核心有几个复杂的JS对象，我们喜欢Mongo，因为我们可以真正、非常容易地持久化所有东西。我们的物体也是相当无定形和非结构化的，蒙古人不眨眼就吸收了这一复杂性。我们有一个定制的报告层，可以为人类消费破译无定形的数据，这并不难开发。

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

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

就个人而言，我认为"nosql"会因碎片化而枯萎和死亡，因为没有固定的标准(几乎按定义)。所以我个人不会为任何长期项目下赌注。

唯一能在我的书中保存"nosql"的是，它是否能够无缝地集成到Ruby或类似的语言中，并使语言"持久"，几乎不需要任何编码和设计开销。这可能会过去，但我会等到那时，而不是现在，当然，它需要更成熟。

顺便问一下，你为什么要从头开始创建一个论坛？有大量的开源论坛可以根据大多数需求进行调整，除非你真的在创建下一代的论坛(我怀疑)。

如果需要复杂的事务，我会说使用RDBMS。否则我会使用MongoDB——更灵活地使用它，您知道它可以在需要时进行扩展。(不过我有偏见-我在MongoDB项目上工作)

你喜欢蒙古人的两个主要原因是

• 模式设计的灵活性(JSON类型文档存储)。
• 可伸缩性——只需添加节点，它就可以很好地横向伸缩。

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

我见过很多公司使用MongoDB从应用程序日志中进行实时分析。它的模式自由度非常适合应用程序日志，在应用程序日志中，记录模式往往随时间变化。此外，它的封顶收集功能也很有用，因为它会自动清除旧数据以使数据适合内存。

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

你知道，所有关于连接和"复杂事务"的东西——但多年前，正是蒙蒂自己解释了提交/回滚的"必要性"，他说"无论如何，所有这些都是在逻辑类(而不是数据库)中完成的"，所以这又是一回事了。对于99%的网络应用程序来说，所需要的是一个愚蠢而整洁、快速的数据存储/检索引擎。

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

我建议你找到最好的组合：如果您需要acid并且想要加入一些表，那么mysql+memcache非常棒。MongoDB+Redis非常适合文档存储NEO4J非常适合图形数据库

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