We offer a platform for video- and audio-clips, photos and vector-grafics. We started with MySQL as the database backend and recently included MongoDB for storing all meta-information of the files, because MongoDB better fits the requirements. For example: photos may have Exif information, videos may have audio-tracks where we to want to store the meta-information of, too. Videos and vector-graphics don't share any common meta-information, etc. so I know, that MongoDB is perfect to store this unstructured data and keep it searchable.
然而，我们仍在继续开发我们的平台并添加新功能。接下来的步骤之一就是为我们的用户提供一个论坛。现在出现的问题是:使用MySQL数据库，这将是一个很好的选择，存储论坛和论坛帖子等或使用MongoDB，这也是?
所以问题是:什么时候使用MongoDB，什么时候使用RDBMS。如果可以选择，你会选择mongoDB还是MySQL，为什么会选择?
谁需要分布式、分片的论坛?也许是Facebook，但除非你要创建一个Facebook的竞争对手，否则就使用Mysql, Postgres或任何你最熟悉的。如果您想尝试MongoDB，可以，但不要期望它为您创造奇迹。它会有它的怪癖和一般的肮脏，就像其他东西一样，如果你真的已经在研究它，我相信你已经发现了。
当然，MongoDB可能被大肆宣传，表面上看起来很简单，但您将遇到更成熟的产品已经克服的问题。不要那么容易被诱惑，而是等待“nosql”成熟，或者死亡。
就我个人而言，我认为“nosql”将会枯萎并死于碎片化，因为没有固定的标准(几乎是根据定义)。所以我个人不会在任何长期项目上下注。
在我的书中，唯一能拯救“nosql”的是，如果它能无缝地集成到Ruby或类似的语言中，并使语言“持久”，几乎没有任何编码和设计上的开销。这可能会发生，但我会等到那时候，而不是现在，当然它需要更成熟。
顺便问一下，你为什么要从零开始创建一个论坛?有大量的开源论坛可以调整以适应大多数需求，除非你真的在创建下一代论坛(我怀疑)。
来存储这些非结构化数据
正如你所说，MongoDB最适合存储非结构化数据。这可以将数据组织成文档格式。这些被称为NoSQL数据存储(MongoDB、CouchDB、Voldemort)的RDBMS替代品对于大规模扩展的应用程序非常有用，并且需要从这些大数据存储中更快地访问数据。
而且这些数据库的实现比常规的RDBMS简单。由于这些是简单的键值或文档样式二进制对象，直接序列化到磁盘中。
这些数据存储不强制ACID属性和任何模式。这没有提供任何事务处理功能。因此，这可以扩大规模，我们可以实现更快的访问(读和写)。
但与之相反，RDBM在数据上强制执行ACID和模式。如果想要处理结构化数据，可以使用RDBM。
我会选择MySQL来创建这类论坛。因为这个规模不会很大。这是一个非常简单(常见)的应用程序，它具有数据之间的结构化关系。
