NoSQL 再次败北——我坚持使用 SQL 的原因

oschina
 oschina
发布于 2014年08月03日
收藏 62

【编者按】NoSQL拥有可扩展性和超高吞吐量的能力,然而这却没有发挥实际的优势,同时它不具备关系数据库所有的智能操作,虽然具有无模式存储的优势,却无形中增加了代码的复杂度。更多的应用证明使用NoSQL如此困难,它仅能成为SQL系统的构件而不是替代品。

这是我第二次为新项目深入调研NoSQL,也是第二次决定放弃NoSQL。跟我上次发表的“为什么选择使用NoSQL如此困难”的结论一样,我们最终决定放弃NoSQL,使用传统关系型数据库。

我从上个帖子的许多评论中得出评估NoSQL的一大问题——其解决方案指向的核心是“取决于你的需求”。但尽管需求明确,仍需要花时间调研并搞清楚 一个特定的NoSQL引擎是否正是你所需。有太多方面,你不可能评估所有的。更糟的是,你得费力的从engine-specific文档中解读出它是否能 够实现你的目标,那些文档大多是类似选择关系型数据或者ACID的解决方案。

相比之下,如果使用关系型SQL数据库,大多数情况下,不管是哪种特定产品,你都能知道它的工作方式,不需要反复比对选择,也比较成熟稳定。选择RDBMS能大大降低做错误决定的风险。

NoSQL的吸引力在于拥有可扩展性和超高吞吐量的能力。就算其扩展性真的优于RDBMS,然而现实世界的事实是,99%的应用程序都不会变更数据 模型。比如Stock Exchange,它是访问量最大的网站之一,它们的商品服务器是运行在MSSQL上的。而且很难想象NoSQL需要多么巨大的存储空间,购买一个60- core、高达6TB内存的服务器基本是不可能的。所以使用NoSQL的实际好处又是什么?

起初我认为无模式存储是NoSQL的一个优势,但我已经改变了我这个观点。至少对于关系型页面应用程序,无模式只不过是在增加代码复杂度。此外,我 喜欢结构,特别是数据结构。在数据归档、文件存储、或事件日志这类数据处理中无模式是很有用的,但是对于非社交类的页面应用程序却没有任何优势。

与关系数据库比起来,文档存储会使程序的每个部分都变得更加复杂。对于那种可以将文件名作为key,文件内容作为value的平行文件存储 (key-value数据库),NoSQL是很有优势的,你可以在这类文件中存储任何所需内容,读取的时候也会很方便,但这种存储很脑残。我的结论 是,NoSQL在管理和优化所存储的文件时是非常复杂的,对于存储的数据内容它一无所知。关系数据库所有的智能操作NoSQL全都没有,你必须用代码来实 现那些SQL自带的功能,这对大多数应用程序来说都是不合理的。

即使是建造NoSQL引擎的人也很难描述自己产品的用例,NoSQL的很多评论都在推销自己的产品,却并没有提供任何特别令人信服的理由。很少有 SaaS应用程序用非关系型数据,现实情况是,RDBMS系统要比NoSQL系统多的多,一旦所有的炒作逐渐停止,NoSQL引擎的数量降到合理的范 围,NoSQL将会成为这些合理应用范围内的有用工具。在未来,我认为NoSQL能够成为SQL系统的构件而不是替代品,现在我依然坚持使用SQL。

原文链接:    NoSQL is a no go once again——Why I'll be sticking with SQL for now

稿源:CSDN

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:NoSQL 再次败北——我坚持使用 SQL 的原因
加载中

最新评论(48

为了吃方便面
为了吃方便面
你能发出这样的文章,我就觉得你是个智障
原版什锦八宝饭
原版什锦八宝饭
还是看场景。
动弹
动弹
对的场景用对的软件
xmut
xmut

引用来自“缪斯的情人”的评论

以ACID完备以及关系型数据库的思维来评价和衡量NoSQL数据库是很片面的,这样的文章除了题目误导人以外,没有产生任何有益的价值,所谓“好钢用在刀刃上”,而不是用在打扮“脸皮”上,这一点是nosql要做的,也是作者要做的。不知道作者什么来历,但看文章来说,技术很浮躁,没有了解透nosql的应用场景,何谈深入?最后一句不是你认为这样,nosql本意不是取代sql,而是not only sql!最后,文章很SB,浪费我时间!CSDN拿题目哗众取宠,题目应该翻译为:我还是无法驾驭NoSQL——这也是我坚持使用SQL的原因
个人觉得楼主想说明的是NoSQL无法适应类似ERP这种复杂关系的场景,难道你驾驭了NoSQL,就能解决包括所有关系数据库的问题??? 做人要低调点!!!!
houyu
houyu
哎 不能这样讲啊. 场景不一样,nosql在某些极高并发的场景下面,表现非常令人吃惊. 只是有点吃cpu...
以前用MySQL和oracle 根本无法想象每秒1W+的更新该怎么搞,我两台MongoDB的小服务器就解决了一切....
ruki
ruki

引用来自“vietor”的评论

当初就有人用这个路子说Git不如SVN好

引用来自“理工小强”的评论

汗 莫非你要说git比svn好么。。。

引用来自“G.”的评论

唉, 真想不出SVN哪一点儿好?

引用来自“理工小强”的评论

。。。 总有那么一点吧

引用来自“vietor”的评论

典型的自我安慰呀,如果真的找点好处的话,就是能够按目录开权限。
我只知道svn缺点一堆 真心不好用
理工小强
理工小强

引用来自“vietor”的评论

当初就有人用这个路子说Git不如SVN好

引用来自“理工小强”的评论

汗 莫非你要说git比svn好么。。。

引用来自“G.”的评论

唉, 真想不出SVN哪一点儿好?

引用来自“理工小强”的评论

。。。 总有那么一点吧

引用来自“vietor”的评论

典型的自我安慰呀,如果真的找点好处的话,就是能够按目录开权限。

引用来自“理工小强”的评论

你确定你的工程级别能需要这么详细的权限控制么 要是按照你的逻辑 linux就比windows好 而且windows一点点都不比linux好(或者反过来)

引用来自“vietor”的评论

目录权限,典型的应用是“部门级别的文档”。“要是按照你的逻辑 linux就比windows好 而且windows一点点都不比linux好”这句话的范围太广,难以回答;但思考一下“DOS为什么被主流淘汰”这个问题吧,或许你们想到答案。
你确定 DOS和Window 之间的差别 和 SVN 和 Git之间的区别一样(或者说)差不多大么 不管你确不确定 我是很不确定 ~~ DOS只有羡慕Windows的 因为差距实在太大 已经没有嫉妒的份了 但是SVN和Git之间视乎嫉妒的情感都没有 ~~ 另外就是一个实际性的问题 windows程序员视乎并不怎么待见Git
vietor
vietor

引用来自“vietor”的评论

当初就有人用这个路子说Git不如SVN好

引用来自“理工小强”的评论

汗 莫非你要说git比svn好么。。。

引用来自“G.”的评论

唉, 真想不出SVN哪一点儿好?

引用来自“理工小强”的评论

。。。 总有那么一点吧

引用来自“vietor”的评论

典型的自我安慰呀,如果真的找点好处的话,就是能够按目录开权限。

引用来自“理工小强”的评论

你确定你的工程级别能需要这么详细的权限控制么 要是按照你的逻辑 linux就比windows好 而且windows一点点都不比linux好(或者反过来)
目录权限,典型的应用是“部门级别的文档”。“要是按照你的逻辑 linux就比windows好 而且windows一点点都不比linux好”这句话的范围太广,难以回答;但思考一下“DOS为什么被主流淘汰”这个问题吧,或许你们想到答案。
理工小强
理工小强

引用来自“vietor”的评论

当初就有人用这个路子说Git不如SVN好

引用来自“理工小强”的评论

汗 莫非你要说git比svn好么。。。

引用来自“G.”的评论

唉, 真想不出SVN哪一点儿好?

引用来自“理工小强”的评论

。。。 总有那么一点吧

引用来自“vietor”的评论

典型的自我安慰呀,如果真的找点好处的话,就是能够按目录开权限。
你确定你的工程级别能需要这么详细的权限控制么 要是按照你的逻辑 linux就比windows好 而且windows一点点都不比linux好(或者反过来)
返回顶部
顶部