所以…这个NoSQL的东西
我一直在看MongoDB，我很着迷。 看起来（尽pipe我必须怀疑）为了换取组织我的数据库的方式，我可以获得与CPU和RAM一样多的性能。 它看起来优雅，灵活，但我不像Rails一样快速交易。 那么有什么问题呢？ 一个关系数据库给了我什么，我不能做到或者根本不能和Mongo一起做？ 换句话说，为什么（除了现有的NoSQL系统的不成熟性和阻力改变之外）不是整个行业从MySQL跳槽？
据我了解，随着规模的扩大，您可以使用MySQL来提供Memcache。 现在看来，我可以从一开始就有同样的performance。
我知道我不能在交往中进行交易……什么时候这会是一个大问题？
我阅读http://teddziuba.com/2010/03/i-cant-wait-for-nosql-to-die.html，但据我所知，他的论点基本上是使用真实工具的真正企业不需要为了避免SQL，所以觉得有必要抛弃它的人做错了。 但是，“企业”不得不面对像Facebook或谷歌那么多的并发用户，所以我没有真正看到他的观点。 （沃尔玛拥有180万名员工，Facebook拥有3亿用户）。
我真的很好奇这个…我保证我不是拖钓。
我也是MongoDB的忠实粉丝。 据说，这绝对不是RDBMS的全面替代品。 Facebook拥有3亿用户，但是如果你的一些朋友一次没有出现在列表中，或者偶尔有一个相册丢失，你会注意到吗？ 可能不会。 如果你的状态更新不会在几分钟内滴落给所有的朋友，那么重要吗？ 几乎不。 如果沃尔玛的资产负债表不同步，有人会失去他们的头脑？ 当然。
NoSQL数据库在“模糊”环境中非常出色，在这种环境中，关系不严格，数据完整性可能会不同步。 当数据集非常复杂和相关（因此名称），而且他们需要保持纯粹的时候，RDBMS仍然很重要。
对NoSQL的巨大推动来自过去30年的事实，我们已经在两种情况下都使用了RDMBS系统。 我们现在有许多情况下更适合的工具。 事实上，有些人会争辩最多。 但是没有人会争辩。
我写这个，但作为雷克斯答案的争议。
我反驳nosql是无关和模糊的想法。
多年以前，我一直和CODASYL一起工作，C和Cobol – CODASYL中的实体关系非常紧密。
相反，关系数据库系统对关系有一个非常自由的政策。 只要你能确定一个外键，你就可以build立一个关系即兴。
SQL常常被认为是RDBMS的同义词，但人们一直在为CODASYL，XML，倒置集合等编写SQL驱动程序。
RDBMS / SQL在数据和关系上并不相同。 事实上，RDBMS一直是造成关系不准确和误解的一个原因。 例如，我不明白RDBMS如何提供比hadoop更好的数据和关系完整性。 穿上一层JDO–我们可以在hadoop中的实体之间构build一个良好和干净的关系networking。
不过，我喜欢使用SQL，因为它使我能够编写adhoc关系，即使我认识到adhoc关系是造成关系瑕疵和问题的一个常见原因。
有了机会进行商业和工业stream程的统计分析，SQL使我有能力探索以前没有任何关系的关系。 使用统计分析的机会给了我一些通常不会成为SQL程序员的方式的见解。
例如，您可以devise并标准化您的模式以反映一组进程。 你可能没有意识到的是，关系随着时间的推移而变化。 统计特征将揭示一个模式可能不再像以前那样被“正确地标准化”了。 这些进程的主要组成部分随着时间而变化。 但是非统计程序员不理解这一点，并继续吹捧RDBMS作为数据完整性和关系精度的完美解决scheme。
但是，在关系链接数据库中，您可以链接关系中的实体。 当关系发生变化时，链接与数据自然变异。 数据库系统中logging了关系及其变异，而不需要重新规范模式的昂贵需求。 在这一点上，RDBMS只能作为临时数据库。
但是你可能会反驳RDBMS也允许你灵活地改变你的关系，因为这是SQL最好的。 诚然，非常真实 – 只要你执行BCNF甚至4NF。 否则，您将开始看到您的查询和数据加载器执行复制操作。 但是，那么在RDBMS业务中你多年的工作至less可以让你意识到BCNF是非常昂贵的，在操作上效率低下，而且我们总是犯我们的模式。
说RDBMS和SQL促进数据和关系完整性是一个严重错误的陈述。 无论你在一家如此小规模的公司工作，或者两年以上都没有留在岗位上 – 你不会看到数据或信息突变以及RDBMS带来的问题。 关系数据库pipe理系统的滥用是由于计算机应用程序受到限制，公司财务失败的原因是由于他们的观点受到程序员的限制，他们的观点仅限于他们的敬爱RDBMS模式。
这就是为什么SQL程序员不明白为什么你的公司统计人员拒绝使用你精心devise的应用程序，但他们聘请了一名大学实习生来编写SQL来将数据下载到他们的个人服务器上，并且你的公司高pipe学会信任会计师和统计人员'电子表格而不是你的优雅的多层应用程序，因为你的应用程序无法进行变异。
这可能是不可能的，但是我仍然要求你获得一些统计理解，以理解过程如何随着时间的推移而变化，以便你能做出正确的技术决策。
人们没有转向SQL的原因在于没有像SQL这样的良好的脚本环境来执行adhoc关系分析。 不是因为无SQL技术在精度或完整性上不足。 由于我们现在快速而敏捷的应用开发态度和策略，Adhoc关系分析现在非常重要。
让我一次一个地提出问题：
我知道我不能做跨越关系的交易…什么时候这是一个大问题？
图片级联删除。 甚至只是基本的参照完整性。 “外键”的概念不能在“集合”（Mongo术语表）中真正实施。 你可以做primefaces写入只有一个“文件”（AKAlogging）。 所以如果你有数据库问题，你可以在数据库中孤立数据。
我可以获得与CPU和RAM一样多的性能吗？
不是免费的，但肯定有不同的权衡。 例如，Mongo擅长运行单一logging，键/值查找。 但是，Mongo在运行关系查询方面很差。 你需要使用map-reduce来处理这些问题。 蒙戈是一个“RAM妓女”。 Mongo基本上要求64位的任何重要的数据集。 Mongo将占用硬盘空间，装载一个140GB的数据库，在交换文件使用过程中，最终可以使用200+ GB。
而你仍然想要一个快速的驱动器。
事实上，我认为可以肯定地说，MongoDB实际上是一个能够迎合尖端硬件（64位，大量RAM，固态硬盘）的数据库系统。 我的意思是，整个数据库是围绕查找RAM中的数据索引数据（hello 64位），然后在驱动器上进行集中的随机查找（hello SSD）。
为什么…整个行业没有从MySQL中跳槽？
- 这不符合ACID标准 。 对于银行系统来说，可能相当糟糕（当然，他们中的大多数仍在处理平面文件，但这是一个不同的问题）。 但是，请注意，您可以强制Mongo写入“安全”，并保证数据到达磁盘，但一次只能有一个“文档”。
- 它还很年轻 。 很多大型企业仍然在使用VB6编写的SQL Server 2000应用程序上运行旧版本的Crystal Reports。 或者他们正在build立企业服务总线来pipe理他们多年来build立的疯狂的异构环境。
- 这是一个非常不同的范例 。 也许我经常在Mongo邮件列表（和这里）上看到的30％的问题从根本上与“我该如何查询X？”有关。 或者“我如何构build这些数据？” 。 使用MongoDB通常需要事先进行非规范化。 这不仅有点困难，而且还没有经过培训。 大多数人只在学校学习“正常化”，没有人教我们如何去规范化表演。
- 这不是一切正确的工具 。 老实说，我认为MongoDB是读写交易数据的好工具。 这个简单的“一次性”CRUD包含了很多现代应用程序。 但是，MongoDB在报告方面并不是很出色。 事实上，我诚恳地设想下一步不是“Mongo for everything”，而是“Mongo for transactional”和“MySQL for reporting” 。 当你的数据变得足够大以至于你扔掉“实时报告”，那么使用Map-Reduce来填充报告数据库似乎并不是那么糟糕。
据我了解，随着规模的扩大，您可以使用MySQL来提供Memcache。 现在看来，我可以从一开始就有同样的performance。
老实说，我正在为我的一些项目努力。 再次，我认为，MongoDB实际上是一个有效的caching层。 事实上，它使一个文件支持的caching层。 所以如果你能够将MySQL更改为Mongo，那么你可以在没有caching遗漏的情况下获得Memcached。 它也可以很容易地在新服务器上“加热caching”，只需复制文件并启动Mongo指向正确的文件夹，这确实很容易。
您认为Facebook多久可以对其数据存储进行任意查询？ 并不是所有的东西都是networking应用程序，反过来也不是每一组数据都需要深入分析。
NoSQL在我看来，主要是对基本上相当于人们使用RDBMS的react native反应，因为人们并不是根据自己的需要主动做出决定，而是select了一些默认的任务。 从整个行业来说，“从MySQL跳槽”（或者说一般的RDBMS）将会一次又一次地犯下同样的错误，钟摆将会以另一种方式摆脱。
如果MongoDB为你的用例工作，一定要继续。 只是不要以为你的用例就是所有的用例。 没有适合所有情况的技术。 超音速喷气机的发明并没有消除货运列车的使用。
对NoSQL的强烈反对根植于许多NoSQL提倡者的心态。 具体来说，这种态度最好的概括为“SQL太难了，我不应该这样做”。 我不喜欢NoSQL，因为在许多情况下似乎是提高了无知。
我知道我不能在交往中进行交易……什么时候这会是一个大问题？
比你期望的更频繁。 当你不能假定一致的数据集时，有很多事情可能会出错。
我已经使用了MongoDB，Redis（超过键值对支持列表，集合和sorting集合），Tokyo Tyrant，Memcached和MySql＆PostgreSQL。
NoSQL DB和基于SQL的数据库之间的争论是完全没有根据的。 您需要根据您的使用情况select合适的模型。如果您需要ACID符合性，请继续使用SQL DB（如PostgreSQL，Oracle等）。您需要高性能，但您不太关心数据，那么您可以考虑使用noSQL DB。 他们是根本不同的技术。 你甚至可以使用模型的组合。 有了NoSQL，你将会错过关系，约束和有时候的事务。事实上，这就是NoSQL更快的原因之一。
一旦我用MongoDB丢失了两个月的汇总数据，我就不知道该如何丢失它们。但是我有备份，并且我已经丢失了几分钟的数据。 我带备份的MongoDB ..如果你使用NoSQL，偶尔备份或计划数据库备份cron作业。 这也适用于SQL DB。
与SQL RDBMS相比，NoSQL DB更年轻，目前正处于完整的开发阶段，但NoSQL DB在其范围内已经成熟，即它们意味着高性能，易于复制。
在我的网站（stacked.in）中，我只使用了redis DB，它的工作速度比MySQL快得多。
请记住，NoSQL并不完全是新的。 毕竟，他们不得不在SQL和关系数据库之前使用一些东西，对吧？ 事实上，像MUMPS和CODASYL这样的系统工作方式也是几十年。 关系数据库给你的是以任意方式查询数据的能力。
假设你有一个客户数据库，他们的购买和他们购买的东西。 NoSQL数据库可能有包含购买和购买项目的客户。 这样可以很容易地找出给定客户购买的物品，但很难找出客户购买的物品。 一个关系数据库将有客户，采购，项目和表格链接到购买的表格。 在SQL中，这两个查询都是微不足道的，数据库引擎为你做了所有的努力工作。
另外，请记住，NoSQL的一部分趋势是牺牲速度，可伸缩性和成本的一致性或可靠性。 关系数据库可以扩展，但并不便宜。 如果您访问http://tpc.org，您可以find同时在数百个内核上运行的RDBMS，每分钟交付数百万笔交易，但是却花费了数百万美元。;
如果你的数据没有利用关系代数，也不需要ACID保证，那么你就不会使用专门用于这些用途的语言。
