何时使用MongoDB或其他面向文档的数据库系统？
我们为视频和音频剪辑，照片和矢量图形提供平台。 我们以MySQL作为数据库后端开始工作，最近还包含了MongoDB，用于存储文件的所有元信息，因为MongoDB更符合要求。 例如：照片可能具有Exif信息，视频可能有音轨，我们也希望存储元信息。 视频和矢量图形不共享任何通用的元信息等，所以我知道，MongoDB非常适合存储这些非结构化数据并保持可搜索。
但是，我们继续开发我们的平台并添加功能。 现在，接下来的步骤之一将是为我们的用户提供一个论坛。 现在出现的问题是：使用MySQL数据库，这对于存储论坛和论坛帖子等是一个很好的选择，或者也可以使用MongoDB。
所以问题是：何时使用MongoDB以及何时使用RDBMS。 你会选择什么，mongoDB或MySQL，如果你有选择，你为什么要采取它？
在NoSQL中：如果只是这么简单，作者写道MongoDB：
MongoDB不是一个关键/值存储，它更多。 这绝对不是一个RDBMS。 我没有在生产中使用过MongoDB，但我已经用它构建了一个测试应用程序，它是一个非常酷的工具包。 它似乎非常高效，并且或者具有或即将具有容错性和自动分片（即可扩展）。 我认为Mongo可能是迄今为止我所见过的最接近RDBMS替代品的东西。 它不适用于所有数据集和访问模式，但它是为典型的CRUD内容而构建的。 存储本质上是一个巨大的散列，并能够选择任何这些密钥，是大多数人使用关系数据库。 如果你的数据库是3NF，并且你不做任何连接（你只是选择了一堆表格并把所有的对象放在一起，AKA大多数人在网络应用中做的），MongoDB可能会为你踢屁股。
然后，在结论中：
需要指出的是，如果你因为无法选择数据库而做出超级棒的事情而被阻止，那么你就错了。 如果你知道mysql，就使用它。 当你真正需要时进行优化。 使用它像ak / v商店，使用它像一个rdbms，但为了上帝的缘故，建立你的杀手级应用程序！ 这对大多数应用程序都无关紧要。 Facebook仍然使用MySQL，很多。 维基百科使用MySQL，很多。 FriendFeed使用MySQL，很多。 NoSQL是一个很好的工具，但它肯定不会成为你的竞争优势，它不会让你的应用变得热门，而且最重要的是，你的用户不会在意这些。
我将如何构建我的下一个应用程序？ 可能Postgres。 我会使用NoSQL吗？ 也许。 我也可能使用Hadoop和Hive。 我可能会将所有内容保存在平面文件中 也许我会开始盗用Maglev。 我会使用最适合的工作。 如果我需要报告，我不会使用任何NoSQL。 如果我需要缓存，我可能会使用东京暴君。 如果我需要ACIDity，我不会使用NoSQL。 如果我需要大量计数器，我会使用Redis。 如果我需要交易，我会使用Postgres。 如果我有大量单一类型的文档，我可能会使用Mongo。 如果我需要每天写10亿个物体，我可能会用Voldemort。 如果我需要全文搜索，我可能会使用Solr。 如果我需要全文搜索易失性数据，我可能会使用Sphinx。
我喜欢这篇文章，我觉得它非常翔实，它很好地概述了NoSQL的风景和炒作。 但是，这是最重要的部分，在RDBMS和NoSQL之间进行选择时，真正有助于问自己正确的问题。 值得阅读的恕我直言。
备用链接到文章
在使用MongoDb进行社交应用两年后，我目睹了没有SQL RDBMS的情况下的真正意义。
我相信98％的项目对于典型的SQL RDBMS可能比NoSQL更好。
存储这些非结构化数据
如你所说，MongoDB最适合存储非结构化数据。 这可以将您的数据组织成文档格式。 这些名为NoSQL数据存储（MongoDB，CouchDB，Voldemort）的RDBMS调用对于大规模扩展并需要从这些大型数据存储更快访问数据的应用程序非常有用。
这些数据库的实现比常规的RDBMS更简单。 因为这些都是简单的键值或文档样式的二进制对象直接序列化到磁盘。 这些数据存储不强制执行ACID属性和任何模式 。 这不提供任何交易能力。 因此，这可以扩大规模，我们可以实现更快的访问（读取和写入）。
但相反，RDBM强制实施数据上的ACID和模式。 如果你想使用结构化数据，你可以继续使用RDBM。
我会选择MySQL来创建这种类型的论坛 。 因为这不会很大。 这是一个非常简单（通用）的应用程序，它在数据之间具有结构化的关系。
链接地址: http://www.djcxy.com/p/64579.html上一篇: When to use MongoDB or other document oriented database systems?