什么时候使用MongoDB或其他面向文档的数据库系统?

我们为视频和音频剪辑、照片和矢量图形提供了一个平台。我们开始使用MySQL作为数据库后端，最近加入了MongoDB来存储文件的所有元信息，因为MongoDB更适合这个需求。例如:照片可能有Exif信息，视频可能有我们想要存储元信息的音轨。视频和矢量图形不共享任何公共元信息，等等，所以我知道，MongoDB是完美的存储这些非结构化数据，并保持其可搜索。

然而，我们仍在继续开发我们的平台并添加新功能。接下来的步骤之一就是为我们的用户提供一个论坛。现在出现的问题是:使用MySQL数据库，这将是一个很好的选择，存储论坛和论坛帖子等或使用MongoDB，这也是?

所以问题是:什么时候使用MongoDB，什么时候使用RDBMS。如果可以选择，你会选择mongoDB还是MySQL，为什么会选择?

126054 次浏览
小开

来存储这些非结构化数据

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

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

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

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

小开

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

小开
最佳答案

在NoSQL:如果有那么简单就好了中，作者写到MongoDB:

MongoDB不是一个键/值存储，它的功能远不止这些。它也绝对不是RDBMS。我还没有在生产中使用MongoDB，但我曾经使用它来构建一个测试应用程序，它是一个非常酷的工具包。它看起来是非常高性能的，或者很快就会有容错和自动分片(也就是它会缩放)。我认为Mongo可能是迄今为止我所见过的最接近RDBMS替代品的东西。它并不适用于所有数据集和访问模式，但它是为典型的CRUD构建的。存储本质上是一个巨大的散列，并能够对这些键进行选择，这是大多数人使用关系数据库的目的。# EYZ0

然后，在结论部分:

如果你知道mysql，就使用它。在实际需要时进行优化。像使用k/v商店一样使用它，像使用rdbms一样使用它，但是看在上帝的份上，创建你的杀手级应用程序!这些对大多数应用来说都无关紧要。Facebook仍然大量使用MySQL。维基百科大量使用MySQL。FriendFeed大量使用MySQL。# EYZ1

我要在什么基础上开发我的下一个应用呢?可能Postgres。我会使用NoSQL吗?也许吧。我也可能使用Hadoop和Hive。我可能会把所有东西都保存在平面文件中。也许我该开始黑磁悬浮了。如果我需要缓存，我可能会使用东京暴君。如果我需要大量的计数器，我会使用Redis。如果我每天需要写10亿个对象，我可能会使用伏地魔。如果我需要全文搜索，我可能会使用Solr。如果我需要对不稳定数据进行全文搜索，我可能会使用Sphinx。

我喜欢这篇文章，我发现它信息丰富，它很好地概述了NoSQL的前景和炒作。但是，这是最重要的部分，当涉及到在RDBMS和NoSQL之间进行选择时，问自己正确的问题真的很有帮助。恕我直言，值得一读。

# EYZ0

小开

谁需要分布式、分片的论坛?也许是Facebook，但除非你要创建一个Facebook的竞争对手，否则就使用Mysql, Postgres或任何你最熟悉的。如果您想尝试MongoDB，可以，但不要期望它为您创造奇迹。它会有它的怪癖和一般的肮脏，就像其他东西一样，如果你真的已经在研究它，我相信你已经发现了。

当然，MongoDB可能被大肆宣传，表面上看起来很简单，但您将遇到更成熟的产品已经克服的问题。不要那么容易被诱惑，而是等待“nosql”成熟，或者死亡。

就我个人而言，我认为“nosql”将会枯萎并死于碎片化，因为没有固定的标准(几乎是根据定义)。所以我个人不会在任何长期项目上下注。

在我的书中，唯一能拯救“nosql”的是，如果它能无缝地集成到Ruby或类似的语言中，并使语言“持久”，几乎没有任何编码和设计上的开销。这可能会发生，但我会等到那时候，而不是现在，当然它需要更成熟。

顺便问一下，你为什么要从零开始创建一个论坛?有大量的开源论坛可以调整以适应大多数需求，除非你真的在创建下一代论坛(我怀疑)。

小开

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

小开

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

  1. 您最终需要编写作业来完成诸如连接来自不同表/集合的数据之类的工作，RDBMS可以自动为您完成这些工作。
  2. NoSQL的查询功能被严重削弱。MongoDb可能是最接近SQL的东西，但它仍然远远落后。相信我。SQL查询是超级直观、灵活和强大的。MongoDb查询则不是。
  3. MongoDb查询只能从一个集合中检索数据，并且只能利用一个索引。MongoDb可能是最灵活的NoSQL数据库之一。在许多场景中，这意味着要多次往返于服务器以查找相关记录。然后你开始反规格化数据——这意味着后台工作。
  4. 它不是关系数据库的事实意味着您不会有(一些人认为是性能较差的)外键约束来确保数据的一致性。我向您保证，这最终将在您的数据库中产生数据不一致。做好准备。很有可能您将开始编写流程或检查以保持数据库的一致性，这可能不会比让RDBMS为您做得更好。
  5. 忘记像hibernate这样成熟的框架吧。

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

小开

我看到很多公司都在使用MongoDB对应用程序日志进行实时分析。它的无模式性非常适合应用程序日志，因为在应用程序日志中，记录模式往往会不时更改。此外，它的限制集合特性也很有用，因为它会自动清除旧数据以保持数据适合内存。

这是我真的认为MongoDB适合的一个领域，但MySQL/PostgreSQL一般更推荐。网络上有很多文档和开发人员资源，以及它们的功能和健壮性。

小开

你可能更喜欢Mongo的两个主要原因是

  • 模式设计的灵活性(JSON类型文档存储)。
  • 可伸缩性——只要增加节点，它就可以很好地横向扩展。

适用于大数据应用。RDBMS不适用于大数据。

小开

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

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

小开

就像之前说的， 你可以在很多选择中选择，看看所有的选择: # EYZ0 < / p > 我的建议是找到你的最佳组合: 如果你需要ACID并且想要连接一些表，MySQL + Memcache真的很好 MongoDB + Redis是完美的文档存储 Neo4J非常适合图形数据库

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


提交答案