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，为什么会选择?
在将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要好得多。
