你好,游客 登录 注册 发布搜索
背景:
阅读新闻

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

[日期:2014-08-03] 来源:CSDN  作者: [字体: ]

  

  这是我第二次为新项目深入调研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。

收藏 推荐 打印 | 录入:574107552 | 阅读:
相关新闻       NoSQL SQL 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款