何时使用MongoDB或其他面向文档的数据库系统？
何时使用MongoDB或其他面向文档的数据库系统？
已关闭。此问题是基于 意见 的。目前无法接受答案。
想要改进这个问题吗？通过编辑此帖子更新问题，以便其可由事实和引文回答。
改善此问题
我们提供一个用于视频、音频剪辑、照片和矢量图形的平台。我们从MySQL作为数据库后端开始，并最近包括MongoDB来存储所有文件的元信息，因为MongoDB更适合这些要求。例如：照片可能具有Exif信息，视频可能具有音轨，我们也要存储其元信息。视频和矢量图形不共享任何常见的元信息，等等。所以，我知道MongoDB非常适合存储这些非结构化数据并保持可搜索性。
然而，我们正在继续开发我们的平台并添加功能。现在下一步将是为我们的用户提供一个论坛。现在出现的问题是：使用MySQL数据库，这将是存储论坛和论坛帖子等的好选择，还是同样使用MongoDB？
因此，问题是：何时使用MongoDB，何时使用关系型数据库。如果您有选择的机会，您会选择MongoDB还是MySQL，为什么会选择它？
在使用MongoDb作为社交应用的数据库两年后，我亲眼看到了没有SQL RDBMS意味着什么。
- 你最终会写一些任务，比如连接来自不同表或集合的数据，这是关系型数据库会自动完成的事情。
- 你在NoSQL中的查询能力被极大地削弱。MongoDb可能是最接近SQL的NoSQL数据库，但它仍然远远落后。相信我，SQL查询非常直观、灵活和强大。MongoDb查询则不是。
- MongoDb的查询只能从一个集合中检索数据，并利用仅一个索引。而MongoDb可能是最灵活的NoSQL数据库之一。在许多情况下，这意味着更多的往返服务器查找相关记录。于是你就开始了反规范化数据，这意味着背景任务。
- 它不是一个关系型数据库意味着你不会有（在一些人看来性能较差的）外键约束来确保你的数据一致性。我向你保证，最终这将在你的数据库中创建数据不一致性。要准备好。最有可能的是，你会开始编写流程或检查来保持你的数据库一致性，这可能不会比让关系型数据库管理器为你执行它更好。
- 忘掉像Hibernate这样成熟的框架吧。
我相信有98%的项目比起NoSQL，使用典型的SQL RDBMS要好得多。
在《NoSQL：如果只是那么简单》一文中，作者谈到了MongoDB：\nMongoDB不仅仅是一个键值对存储，它更强大。它绝非关系型数据库(RDBMS)。我没有在生产环境中使用过MongoDB，但我曾经用它来构建一个测试应用程序，它是一个非常酷的工具。它似乎非常高效，并且已经具备或者即将具备容错和自动分片(也就是它可以进行横向扩展)。我认为Mongo可能是我目前看到的最接近替代RDBMS的东西。它并不适用于所有的数据集和访问模式，但是它适合于你典型的\"增删改查\"的需求。存储的基本上是一个巨大的哈希表，能够选择其中的任何一个键，这正是大多数人使用关系型数据库的原因。如果你的数据库符合第三范式并且没有执行任何连接操作(你只是在选择一堆表并将所有对象组合在一起，这就是大多数Web应用程序中的做法)，那么MongoDB可能非常适合你。\n\n接着，在结论部分：\n真正需要指出的是，如果你因为无法选择数据库而被拖延，那么你是在做错事。如果你知道mysql，那就使用它。在确实需要时进行优化。像键值存储一样使用它，像关系型数据库一样使用它，但是请建立您的杀手级应用程序！这些对于大多数应用程序都是无关紧要的。Facebook仍然大量使用MySQL。维基百科大量使用MySQL。FriendFeed大量使用MySQL。NoSQL是一个伟大的工具，但它绝不会成为你的竞争优势，它不会使你的应用程序\"火热\"，最重要的是，你的用户不会关心这些。我下一个应用程序要使用什么来构建呢？可能是Postgres。我会使用NoSQL吗？也许吧。我也可能使用Hadoop和Hive，或者把所有数据都存储在平面文件中。也许我会开始研究Maglev。我会根据任务的需要使用最优秀的方案。如果我需要报告，就不会使用任何NoSQL。如果我需要缓存，可能会使用Tokyo Tyrant。如果我需要ACID性，我就不会使用NoSQL。如果我需要很多计数器，我会使用Redis。如果我需要事务，我会使用Postgres。如果我有大量单一类型的文档，我可能会使用Mongo。如果我需要每天写入10亿个对象，我可能会使用Voldemort。如果我需要全文搜索，我可能会使用Solr。如果我需要全文搜索易变数据，我可能会使用Sphinx。\n\n我喜欢这篇文章，我觉得它非常有用，它提供了对NoSQL领域的概述和热度。但是，最重要的部分是，当选择关系数据库管理系统和NoSQL之间时，它确实有助于提出正确的问题。IMHO值得一读。原文链接。