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

我们有一个系统，它的核心有几个复杂的JS对象，我们喜欢Mongo，因为我们可以很容易地持久化所有东西。我们的对象也相当无定形和无结构，Mongo毫不眨眼地吸收了这种复杂性。我们有一个自定义的报告层，它可以为人类消费破译无定形的数据，这并不难开发。

就像之前说的， 你可以在很多选择中选择，看看所有的选择: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

我的建议是找到你的最佳组合: 如果你需要ACID并且想要连接一些表，MySQL + Memcache真的很好 MongoDB + Redis是完美的文档存储 Neo4J是完美的图形数据库

我做什么:我开始使用MySQl + Memcache，因为我习惯了，然后我开始使用其他数据库框架。在一个项目中，你可以结合MySQL和MongoDB为例!

来存储这些非结构化数据

正如你所说，MongoDB最适合存储非结构化数据。这可以将数据组织成文档格式。这些被称为NoSQL数据存储(MongoDB、CouchDB、Voldemort)的RDBMS替代品对于大规模扩展的应用程序非常有用，并且需要从这些大数据存储中更快地访问数据。

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

但与之相反，RDBM在数据上强制执行ACID和模式。如果想要处理结构化数据，可以使用RDBM。

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

我看到很多公司都在使用MongoDB对应用程序日志进行实时分析。它的无模式性非常适合应用程序日志，因为在应用程序日志中，记录模式往往会不时更改。此外，它的Capped Collection功能也很有用，因为它会自动清除旧数据以保持数据适合内存。

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

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

我们有一个系统，它的核心有几个复杂的JS对象，我们喜欢Mongo，因为我们可以很容易地持久化所有东西。我们的对象也相当无定形和无结构，Mongo毫不眨眼地吸收了这种复杂性。我们有一个自定义的报告层，它可以为人类消费破译无定形的数据，这并不难开发。

在《NoSQL: If Only It Was That Easy》一书中，作者这样描述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之间进行选择时，问自己正确的问题真的很有帮助。恕我直言，值得一读。

文章的替代链接