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,为什么会选择?


当前回答

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

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

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

其他回答

你知道,所有这些关于连接和“复杂事务”的东西——但许多年前是Monty自己解释了COMMIT / ROLLBACK的“必要性”,他说“所有这些都是在逻辑类(而不是数据库)中完成的”——所以这是同样的事情。我们所需要的是一个愚蠢但非常整洁和快速的数据存储/检索引擎,用于99%的web应用程序。

如果需要复杂的事务,我会建议使用RDBMS。否则我会选择MongoDB,它工作起来更灵活,你知道它可以在你需要的时候扩展。(虽然我有偏见-我在MongoDB项目工作)

来存储这些非结构化数据

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

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

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

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

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

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

在将MongoDb用于社交应用程序两年后,我已经见证了没有SQL RDBMS的真正意义。

You end up writing jobs to do things like joining data from different tables/collections, something that an RDBMS would do for you automatically. Your query capabilities with NoSQL are drastically crippled. MongoDb may be the closest thing to SQL but it is still extremely far behind. Trust me. SQL queries are super intuitive, flexible and powerful. MongoDb queries are not. MongoDb queries can retrieve data from only one collection and take advantage of only one index. And MongoDb is probably one of the most flexible NoSQL databases. In many scenarios, this means more round-trips to the server to find related records. And then you start de-normalizing data - which means background jobs. The fact that it is not a relational database means that you won't have (thought by some to be bad performing) foreign key constrains to ensure that your data is consistent. I assure you this is eventually going to create data inconsistencies in your database. Be prepared. Most likely you will start writing processes or checks to keep your database consistent, which will probably not perform better than letting the RDBMS do it for you. Forget about mature frameworks like hibernate.

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