那么......这个NoSQL的东西

我一直在看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亿用户).

我真的好奇这个...我保证我不会拖钓.

我也是MongoDB的忠实粉丝.话虽如此,它绝对不是RDBMS的全部替代品.Facebook有3亿用户,但是如果你的一些朋友没有出现在列表中,或者偶尔的请求中缺少一张相册,你会注意到吗？可能不是.如果您的状态更新没有在几分钟内传达给所有朋友,那有关系吗？几乎不.如果沃尔玛的资产负债表不同步,有人会失去理智吗？当然.

NoSQL数据库在"模糊"环境中非常出色,在这种环境中,关系不严格,数据完整性可能会导致不同步.当数据集非常复杂和关系(因此名称)时,RDBMS仍然很重要,并且它们需要保持纯粹.

对NoSQL的大力推动来自于过去30年的事实,我们一直在使用RDMBS系统.我们现在有一个适合许多情况的更合适的工具.事实上,有些人会争论最多.但没有人会争辩.

我写这个但是作为对雷克斯答案的争议.

我怀疑nosql是无关的和模糊的.

多年前,我和C和Cobol一起使用CODASYL - CODASYL的实体关系非常紧密.

相比之下,关系数据库系统对关系有非常宽松的政策.只要你能识别出一个外键,就可以形成一种关系.

经常认为SQL是RDBMS的同义词,但人们一直在为CODASYL,XML,倒置集等编写SQL驱动程序.

RDBMS/SQL在数据或关系方面不等于精度.实际上,RDBMS一直是不精确和误解关系的常见原因.例如,我没有看到RDBMS如何提供比hadoop更好的数据和关系完整性.加上一层JDO - 我们可以在hadoop中构建一个实体之间良好而清晰的关系网络.

但是,我喜欢使用SQL,因为它让我能够编写adhoc关系,即使我发现adhoc关系是关系掺假和问题的常见原因.

有机会使用业务和工业流程的统计分析,SQL让我能够探索以前没有感知过任何关系的关系.使用统计分析的机会给了我通常不会成为SQL程序员的见解.

例如,您可以设计和规范化模式以反映一组进程.您可能没有意识到的是,关系随着时间而变化.统计特征将揭示一个模式可能不再像过去那样"正确地标准化".这些过程的主要组成部分随着时间的推移发生了变异.但非统计程序员并不了解这一点,并继续称RDBMS为数据完整性和关系精度的完美解决方案.

但是,在关系链接数据库中,您可以在关系中链接实体.当关系发生变异时,链接会自然地与数据发生变异.关系及其变异记录在数据库系统中,而不需要重新规范模式.此时,RDBMS仅作为临时dbs.

但是你可能会反驳说RDBMS也允许你灵活地改变你的关系,因为这是SQL最擅长的.是的,非常正确 - 只要你执行BCNF甚至4NF.否则,您将开始看到您的查询和数据加载器执行复制操作.但是到目前为止,你在RDBMS业务中的多年工作至少让你意识到BCNF非常昂贵且操作效率低下,而且我们总是因为我们的架构而感到内疚.

要说RDBMS和SQL促进数据和关系完整性是一个严重的错误陈述.要么你在一家如此小的公司工作,要么你没有在你的岗位上工作超过两年 - 你就不会看到数据量或信息突变以及RDBMS引起的问题.滥用RDBMS是导致高管受到计算机应用程序限制的原因以及公司未能看到市场行为变化导致财务失败的原因,因为他们的观点受到程序员的限制,他们的观点仅限于他们对他们心爱的人的崇敬RDBMS模式.

这就是为什么SQL程序员不明白为什么你的公司统计学家拒绝使用你精心设计的应用程序,但是他们聘请了大学实习生编写SQL来将数据下载到他们的个人服务器中,并且你的公司高管学会信任会计师和统计人员'电子表格而不是优雅的多层应用程序,因为您的应用程序无法随进程变异.

这可能是不可能的,但我仍然敦促你获得一些统计学的理解,以便了解过程如何随着时间的推移而发生变异,从而使你能够做出正确的技术决策.

人们没有转向无SQL的原因是缺乏像SQL这样的良好脚本环境来执行特殊关系分析.不是因为无SQL技术在精度或完整性方面存在缺陷.由于我们现在拥有的快速灵活的应用程序开发态度和策略,特殊关系分析现在非常重要.

让我一次一个地回答问题:

我知道我不能跨越关系进行交易......什么时候这会是一个大问题？

图片级联删除.甚至只是基本的参照完整性."外键"的概念不能真正贯穿"集合"(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跳出来的？

它不符合ACID标准.可能对银行系统来说非常糟糕(当然,他们中的大多数仍在处理平面文件,但这是一个不同的问题).但请注意,您可以强制使用Mongo进行"安全"写入,并保证数据到达磁盘,但一次只能使用一个"文档".

它还很年轻.许多大企业仍然在用VB6编写的SQL Server 2000应用程序上运行旧版本的Crystal Reports.或者他们正在构建企业服务总线来管理他们多年来积累的疯狂的异构环境.

这是一个非常不同的范例.也许我经常在Mongo邮件列表上看到的问题中有30%(和这里)基本上与"我如何查询X？"有关.或"我如何构建这些数据？" .使用MongoDB通常需要提前进行非规范化.这不仅有点困难,而且未经训练.大多数人只在学校学习"规范化",没有人教我们如何对表现进行非规范化.

它不是适合一切的正确工具.老实说,我认为MongoDB是阅读和编写事务数据的绝佳工具.这个简单的"一次性"CRUD包含许多现代应用程序.但是,MongoDB在报告方面并不是很出色.事实上,我老实说设想下一步不是"Mongo for everything",它是"Mongo for transactional"和"MySQL for reporting".当您的数据变得足够大以至于丢弃"实时报告"时,使用Map-Reduce填充报告数据库似乎并不那么糟糕.

据我了解,随着您的扩展,您可以使用MySQL来提供Memcache.现在看起来我可以从一开始就以同样高效的方式开始.

老实说,我正在为我的一些项目努力.同样,我认为MongoDB实际上确实构建了一个有效的缓存层.实际上,它构成了一个文件支持的缓存层.因此,如果您能够将MySQL更改推送到Mongo,那么您将获得没有缓存未命中的Memcached.它还可以轻松地在新服务器上"加热缓存",只需复制文件并启动Mongo指向正确的文件夹,这真的很容易.

您认为Facebook对其数据存储区进行任意查询的频率如何？并非所有内容都是Web应用程序,相反,并非每一组数据都需要深入分析.

在我看来,NoSQL很大程度上反映了人们使用RDBMS来完成他们不适合的任务,因为人们没有主动根据他们的需求做出决定并选择了一些默认值.在整个行业范围内"从MySQL跳出来"(或者一般来说是RDBMS)将会再次犯同样的错误,并且钟摆将以另一种方式向后摆动.

如果MongoDB适用于您的用例,请务必继续.只是不要假设您的用例是所有用例.没有适合所有情况的技术.超音速喷气式飞机的发明并没有消除货运列车的使用.