【编者按】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。

原文地址：http://www.adminso.com/articles/view/92253

(站长搜索- http://www.adminso.com/articles -资讯，中国最具专业的站长资讯新闻频道,报道国内外动态权威的站长资讯动向,关注新闻,透视事件热点资讯。)