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

在 NoSQL: If Only It Was That Easy ,作者撰写了关于MongoDB的文章:

MongoDB不是一个密钥/值存储,它比以前多了很多。它也绝对不是RDBMS。我在生产中没有使用MongoDB,但是我使用它构建了一个测试应用程序,它是一个非常酷的工具包。它似乎表现得很好,要么有,要么很快就会有容错和自动切分(也就是说它将扩展)。我认为Mongo可能是迄今为止我所见过的最接近RDBMS的替代产品。它不适用于所有数据集和访问模式,但它是为典型的CRUD构建的。存储本质上是一个巨大的哈希,并且能够在这些键上进行选择,这是大多数人使用关系数据库的目的。 如果你的数据库是3nf,而你不做任何连接(你只需要选择一堆表并把所有的对象放在一起,也就是大多数人在网络应用程序中所做的),MongoDB可能会帮你踢屁股。

那么,在结论中:

真正需要指出的是,如果你因为选择一个数据库而无法做出超棒的事情,那么你就错了。 如果你知道mysql,就用它吧。在实际需要时进行优化。像K/V商店一样使用它,像RDBMS一样使用它,但是看在上帝的份上,构建你的杀手应用!这对大多数应用程序来说都无关紧要。Facebook仍然使用MySQL,很多。维基百科经常使用MySQL。FriendFeed经常使用MySQL。 NoSQL是一个很好的工具,但它肯定不会成为你的竞争优势,也不会让你的应用变得火爆,而且最重要的是,你的用户不会在意这些。

我要在什么上构建下一个应用程序?可能是Postgres。我要用nosql吗?也许吧。我也可以用Hadoop和Hive。我可能把所有的东西都放在平面文件里。也许我会开始窃听磁悬浮技术。 我会用任何对工作最有利的东西。 如果我需要报告,我不会使用任何NoSQL。 如果我需要缓存,我可能会使用东京暴君。 如果我需要酸度,我不会使用nosql。 如果我需要大量的计数器,我会使用Redis。 如果我需要交易,我会使用Postgres。 如果我有大量单一类型的文档,我可能会使用Mongo。 如果我每天需要写10亿个对象,我可能会使用伏地魔。如果我需要全文搜索,我可能会使用solr。如果我需要对易变数据进行全文搜索,我可能会使用sphinx。

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

Alternate link to article

在使用MongoDB开发社交应用程序两年后,我见证了没有SQL RDBMS的生活真正意味着什么。

1. 您最终会编写一些工作来做一些事情,比如连接来自不同表/集合的数据,这是RDBMS自动为您做的事情。
2. NoSQL的查询功能严重受损。MongoDB可能是最接近SQL的东西,但它仍然远远落后于SQL。相信我。SQL查询非常直观、灵活和强大。MongoDB查询不是。
3. MongoDB查询只能从一个集合中检索数据,并且只能利用一个索引。MongoDB可能是最灵活的NoSQL数据库之一。在许多情况下,这意味着需要更多地往返于服务器以查找相关记录。然后你开始去规范化数据——这意味着后台作业。
4. 事实上,它不是一个关系数据库,这意味着您将不会(被一些人认为是性能不佳)使用外键约束来确保数据的一致性。我向您保证,这最终将在您的数据库中创建数据不一致。做好准备。最有可能的情况是,您将开始编写过程或检查以保持数据库的一致性,这可能不会比让RDBMS为您编写更好。
5. 忘记像Hibernate这样的成熟框架。

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

存储这些非结构化数据

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

这些数据库的实现比常规的RDBMS简单。因为这些是直接序列化到磁盘中的简单键值或文档样式的二进制对象。 这些数据存储不强制 酸性质 和任何 图式 . 这不提供任何 交易 能力。因此,这可以扩大规模,我们可以实现更快的访问(读写)。

但是相反,RDBM在数据上强制使用ACID和模式。如果您想使用结构化数据,可以继续使用RDBM。

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

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

我们有一个系统,它的核心有几个复杂的JS对象,我们喜欢Mongo,因为我们可以真正、非常容易地持久化所有东西。我们的物体也是相当无定形和非结构化的,蒙古人不眨眼就吸收了这一复杂性。我们有一个定制的报告层,可以为人类消费破译无定形的数据,这并不难开发。

如果需要复杂的事务,我会说使用RDBMS。否则我会选择MongoDB——更灵活的工作方式,您知道它可以在需要时扩展。(不过我有偏见-我在MongoDB项目上工作)

谁需要分布式、分片的论坛?也许是Facebook,但除非你正在创建一个Facebook的竞争对手,否则只需使用MySQL、Postgres或任何你最喜欢的东西。如果你想试试MongoDB,好吧,但不要指望它能为你变魔术。它会有它的怪癖和普遍的污秽,就像其他一切一样,我相信你已经发现了,如果你真的已经在研究它。

当然,MongoDB可能会被炒作,表面上看起来很容易,但是你会遇到一些更成熟的产品已经克服的问题。不要那么容易被引诱,而是等到“nosql”成熟或死亡。

就个人而言,我认为“nosql”会因碎片化而枯萎和死亡,因为没有固定的标准(几乎按定义)。所以我个人不会为任何长期项目下赌注。

唯一能在我的书中保存“nosql”的是,它是否能够无缝地集成到Ruby或类似的语言中,并使语言“持久”,几乎不需要任何编码和设计开销。这可能会过去,但我会等到那时,而不是现在,当然,它需要更成熟。

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

我见过很多公司使用MongoDB从应用程序日志中进行实时分析。它的模式自由度非常适合应用程序日志,在应用程序日志中,记录模式往往随时间变化。此外,它的 Capped Collection 此功能非常有用,因为它会自动清除旧数据以使数据适合内存。

这是我认为MongoDB非常适合的一个领域,但一般来说,mysql/postgresql更推荐。Web上有很多文档和开发人员资源,以及它们的功能和健壮性。

你喜欢蒙古人的两个主要原因是

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

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

你知道,所有关于连接和“复杂事务”的东西——但多年前,正是蒙蒂自己解释了提交/回滚的“必要性”,他说“无论如何,所有这些都是在逻辑类(而不是数据库)中完成的”,所以这又是一回事了。对于99%的网络应用程序来说,所需要的是一个愚蠢而整洁、快速的数据存储/检索引擎。

如前所述, 您可以在许多选择中进行选择,查看所有这些选择: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

我建议你找到最好的组合: 如果您需要acid并且想要加入一些表,那么mysql+memcache非常棒。 MongoDB+Redis非常适合文档存储 NEO4J非常适合图形数据库

我所做的:我从mysql+memcache开始,因为我习惯了,然后我开始使用其他数据库框架。在单个项目中,您可以将MySQL和MongoDB结合起来!