我一直在关注MongoDB，我很着迷。看来（虽然我必须怀疑），为了换取以稍微不同的方式组织我的数据库，我获得的性能与我有免费的CPU和RAM一样多吗？它看起来很优雅，而且很灵活，但我并不是像Rails一样快速交易。那捕获的是什么？关系数据库给我的是什么，我不能与Mongo一样好或根本不能做什么？换句话说，为什么（除了现有NoSQL系统的不成熟和改变的抵制）整个行业不会从MySQL跳槽？
据我了解，随着您的扩展，您可以使用MySQL来提供Memcache。现在看起来我可以从一开始就以同样高效的方式开始。
我知道我不能跨越关系进行交易......这什么时候会有什么大不了的？
我读了http://teddziuba.com/2010/03/i-cant-wait-for-nosql-to-die.html，但据我所知，他的论点基本上是使用真实工具的真实企业不需要避免SQL，所以那些觉得有必要抛弃它的人做错了。但是，没有“企业”必须处理几乎与Facebook或谷歌一样多的并发用户，所以我真的没有看到他的观点。 （沃尔玛拥有180万名员工; Facebook拥有3亿用户）。
我对此真的很好奇...我保证我不会拖钓。
答案 0 :(得分：64)
我也是MongoDB的忠实粉丝。话虽如此，它绝对不是RDBMS的全部替代品。 Facebook拥有3亿用户，但如果你的一些朋友没有出现在列表中，或者偶尔的请求中缺少一张相册，你会注意到吗？可能不是。如果您的状态更新没有在几分钟内传达给所有朋友，那有关系吗？几乎不。如果沃尔玛的资产负债表不同步，有人会失去理智吗？肯定。
NoSQL数据库在“模糊”环境中非常出色，在这种环境中，关系不严格，数据完整性可能会导致不同步。当数据集极其复杂且关系密切（因此得名）时，RDBMS仍然很重要，并且它们需要保持纯粹。
对NoSQL的大力推动来自于过去30年的事实，我们一直在使用RDMBS系统。我们现在有一个适合许多情况的更合适的工具。事实上，有些人会争论最多。但没有人会争辩。
答案 1 :(得分：14)
我写这个但是作为对雷克斯答案的争议。
我对nosql没有关系和模糊的想法提出异议。
多年前，我和C和Cobol一起使用CODASYL - CODASYL的实体关系非常紧张。
相反，关系数据库系统对关系有非常宽松的政策。只要你能识别出一个外键，你就可以建立一种关系。SQL经常被认为是RDBMS的同义词，但人们一直在为CODASYL，XML，反向集等编写SQL驱动程序。
RDBMS / SQL在数据或关系方面不等于精度。实际上，RDBMS一直是不精确和误解关系的常见原因。例如，我没有看到RDBMS如何提供比hadoop更好的数据和关系完整性。加上一层JDO - 我们可以在hadoop中构建一个实体之间良好和清晰关系的网络。
但是，我喜欢使用SQL，因为它使我能够编写特殊关系的脚本，即使我意识到特殊关系是关系掺假和问题的常见原因。
有机会对业务和工业流程进行统计分析，SQL让我能够探索以前没有感知过任何关系的关系。使用统计分析的机会给了我通常不会成为SQL程序员的见解。
例如，您可以设计和规范化架构以反映一组流程。您可能没有意识到的是，关系随着时间而变化。统计特征将揭示一个模式可能不再像过去那样“正确地标准化”。这些过程的主要组成部分随着时间的推移发生了变异。但非统计程序员并不了解这一点，并继续将RDBMS视为数据完整性和关系精度的完美解决方案。
但是，在关系链接数据库中，您可以在关系中链接实体。当关系发生变异时，链接会自然地与数据发生变异。关系及其变异记录在数据库系统中，而不需要重新规范模式。此时，RDBMS仅作为临时dbs。
但是你可能会反驳说RDBMS也允许你灵活地改变你的关系，因为这是SQL最擅长的。是的，非常正确 - 只要你执行BCNF甚至4NF。否则，您将开始看到您的查询和数据加载器执行复制操作。但是到目前为止，你在RDBMS业务方面的多年工作至少让你意识到BCNF非常昂贵且操作效率低下，而且我们总是因为我们的架构而感到内疚。
要说RDBMS和SQL提升数据和关系完整性是一个严重的错误陈述。要么你在一家如此小的公司工作，要么你没有在你的岗位上工作超过两年 - 你就不会看到数据量或信息突变以及RDBMS引起的问题。滥用RDBMS是导致高管受到计算机应用程序限制的原因以及公司未能看到市场行为变化导致财务失败的原因，因为他们的观点受到程序员的限制，他们的观点仅限于他们对他们心爱的人的崇敬RDBMS模式。
这就是为什么SQL程序员不明白为什么你的公司统计学家拒绝使用你精心设计的应用程序，但是他们聘请了大学实习生编写SQL来将数据下载到他们的个人服务器中，并且你的公司高管学会信任会计师'和统计人员的电子表格而不是优雅的多层应用程序，因为您的应用程序无法随进程变异。
这可能是不可能的，但我仍然敦促你获得一些统计学的理解，以了解过程如何随着时间的推移而变异，以便你做出正确的技术决策。
人们没有转向无SQL的原因是缺乏像SQL这样的良好脚本环境来执行特殊关系分析。不是因为无SQL技术在精度或完整性方面存在缺陷。由于我们现在快速灵活的应用程序开发态度和策略，临时关系分析非常重要。
答案 2 :(得分：10)
让我一次看一个问题：
我知道我不能跨越关系进行交易......这什么时候会有什么大不了的？
图片级联删除。甚至只是基本的参照完整性。 “外键”的概念不能真正贯穿“集合”（Mongo术语表）。您只能对单个“文档”（AKA记录）进行原子写入。因此，如果您遇到数据库问题，您可以在数据库中孤立数据。
我获得了与CPU和RAM一样多的性能吗？
不是免费的，但绝对有一套不同的权衡取舍。例如，Mongo非常擅长运行单记录，键/值查找。但是，Mongo在运行关系查询方面很差。你需要为其中许多使用map-reduce。 Mongo是一个“RAM妓女”。对于任何重要的数据集，Mongo基本上都需要64位。 Mongo将占用驱动器空间，加载140GB的数据库，并且当交换文件在使用期间增长时，最终可能会使用200 GB以上。
你仍然想要快速驾驶。
事实上，我认为可以说MongoDB真的是一个迎合领先硬件（64位，大量RAM，SSD）的数据库系统。我的意思是，整个数据库的核心是在RAM（hello 64位）中查找数据索引数据，然后在驱动器（hello SSD）上进行聚焦随机查找。
为什么......整个行业并没有从MySQL中跳槽？
据我了解，随着您的扩展，您可以使用MySQL来提供Memcache。现在看起来我可以从一开始就以同样高效的方式开始。
老实说，我正在为我的一些项目努力。同样，我认为MongoDB实际上确实构建了一个有效的缓存层。实际上，它构成了一个文件支持的缓存层。因此，如果您能够将MySQL更改推送到Mongo，那么您将获得没有缓存未命中的Memcached。它还可以轻松地在新服务器上“加热缓存”，只需复制文件并启动Mongo指向正确的文件夹，这真的很容易。
答案 3 :(得分：7)
您认为Facebook对其数据存储区进行任意查询的频率如何？并非所有内容都是Web应用程序，相反，并非每一组数据都需要深入分析。
NoSQL在我看来，很大程度上反映了人们使用RDBMS来完成他们不适合的任务的基本等价，因为人们没有根据他们的需求主动做出决定并选择了一些默认值。在整个行业范围内“从MySQL跳出来”（或者一般来说是RDBMS）将会再次犯同样的错误，并且钟摆将以另一种方式向后摆动。
如果MongoDB适用于您的用例，请务必继续。只是不要假设您的用例是所有用例。没有适合所有情况的技术。超音速喷气式飞机的发明并没有消除货运列车的使用。
答案 4 :(得分：2)
对NoSQL的强烈反对根植于许多NoSQL倡导者的心态。具体来说，态度最好总结为“SQL太难了，我不应该这样做”。我不喜欢NoSQL，因为在许多情况下似乎提升了无知。
我知道我不能跨越关系进行交易......这什么时候会有什么大不了的？
比您预期的更频繁。当你不能假设一致的数据集时，有很多事情可能会出错。
答案 5 :(得分：2)
我使用过MongoDB，Redis（超过键值对支持列表，设置和排序集），Tokyo Tyrant，Memcached和MySql＆amp;的PostgreSQL。
NoSQL DB和基于SQL的DB之间的争论是完全没有根据的。您需要根据您的使用案例选择合适的模型。如果您需要ACID合规性，请继续使用PostgreSQL，Oracle等SQL DB。您需要高性能，但不太关心数据，那么您可以考虑使用noSQL DB。它们是根本不同的技术。您甚至可以使用模型组合。使用NoSQL，你将缺少关系，约束和有时交易。实际上，这就是NoSQL更快的原因之一..
一旦我用MongoDB丢失了两个月的汇总数据..不知道我是怎么丢失它们的。但是我有备份而且我丢失了几分钟的数据。我用备份带回了MongoDB ..如果你使用NoSQL，偶尔备份或安排cron作业进行数据库备份。这也适用于SQL DB。
与SQL RDBMS相比，NoSQL DB更年轻，目前正在进行全面开发，但NoSQL DB在其范围内已经成熟，即它们意味着高性能，易于复制。
在我的网站（stacked.in）中，我只使用了redis DB，它的工作速度比MySQL快得多。
答案 6 :(得分：2)
请记住，NoSQL并不是全新的。毕竟，他们必须在SQL和关系数据库之前使用一些东西，对吧？事实上，MUMPS和CODASYL等系统的工作方式相同，而且已有数十年的历史。关系数据库为您提供的是以任意方式查询数据的能力。
假设您拥有一个包含客户，购买商品和购买商品的数据库。 NoSQL DB可能包含包含项目的购买和购买的客户。这样可以很容易地找出给定客户购买的商品，但很难找到客户购买特定商品的内容。关系数据库将具有用于客户，购买，项目以及将项目链接到购买的表格的表格。在SQL中，两个查询都很容易制定，数据库引擎会为您完成所有艰苦的工作。
另外，请记住，NoSQL趋势的一部分是牺牲速度，可扩展性和成本的一致性或可靠性。关系数据库可以扩展，但它并不便宜。如果你转到http://tpc.org，你可以找到同时在数百个内核上运行的RDBMS，每分钟可以交付数百万个交易，但是它们需要花费数百万美元。
答案 7 :(得分：0)
如果您的数据没有利用关系代数，也不需要ACID保证，那么您就不会通过使用专门用于这些用途的语言来获得任何东西。