【51CTO独家特稿】在那篇文章收到的评论当中，很多读者朋友都纠结于对NoSQL的评估难题身上——相关利基解决方案数以百万计，因此实际效果如何“取决于用户的实际需求。”即使我们已经明确了自己的需求，仍然需要通过深入的研究与学习来掌握特定NoSQL引擎是否有能力满足这类需求。大家可能无法对这么多解决方案进行一一评估，毕竟其数量实在太过庞大。更糟糕的是，我们还被迫阅读大量特定引擎的说明文档，从而了解自己要如何借助NoSQL达到自己的预期效果——而其中大部分内容似乎是在高度关注用户是否拥有关系型数据或者是否喜爱ACID事务处理方式。
相比之下，关系型SQL数据库就拥有非常突出的优势，大家很清楚该引擎能够在任何产品当中发挥同样的作用。我们需要面对的选择数量也更少，而且这类选项往往更成熟也经过了时间的检验。也就是说，大家作出糟糕判断的可能性要远远低于RDBMS。
NoSQL的***吸引力源自其向外扩展的便捷性与强大的数据吞吐能力。尽管能够拥有可以与RDBMS相媲美的可扩展性确实令人心动，但现实告诉我们、99%的应用程序在执行流程中根本不会对扩展性提出任何要求。大家可以看看Stack Exchange，他们是世界上现存的最繁忙的站点，并且利用商用服务器运行数据库系统。为了承载这样的工作负载，该网站直接购买了一台拥有60核心服务器并配备6TB的内存容量，事实上我们很难想象这样的设备还需要什么后续扩展。因此，请大家认真考虑这样一个问题：我们是否真能从NoSQL的可扩展能力身上获得实际收益？
NoSQL无存储模式成弊端？
起初笔者认为NoSQL文档存储的无模式特性会成为一大优势，然而笔者在随后的调查当中逐渐改变了自己的观点。至少就关系Web应用程序而言，无模式机制只会造成代码复杂程度的提升、并没有任何其它贡献。更进一步，笔者喜欢结构、特别是清晰的数据结构。诚然，如果大家打算构建一套特殊类型的数据库，用于处理数据归档、文件存储或者事件日志之类任务，那么无模式机制确实有其独特优势。但对于无此需求的Web应用程序来说，NoSQL则显得无甚意义——毕竟这不是社交网络。
与关系型数据库相比，采用文档存储机制会让大家的软件在各个层面上迎来更突出的复杂性难题。我们可以将NoSQL视为一套单纯的文件存储系统，其中文件名代表键、而文件内容则代表值。大家可以在这些文件当中保存任何内容，并快速对其进行读取与写入，然而存储背后并不存在任何处理能力。（当然，在这里笔者要归纳一下，NoSQL引擎在对这些文件进行管理与优化方面表现优异，但却对数据内容本身一无所知。）关系型数据库当中的内容认知特性全部消失，这迫使大家只能自行完成SQL代码能够自动处理的各项事务……而且是针对每一款应用程序。这样的日常成本对于大多数应用程序而言都是不必要也是不可接受的。
即使是那些有能力创建NoSQL引擎的卓越技术人才自己也很难对自己的产品进行用例描述。通过相关评论可以看到，不少开发者都在努力宣传自己的产品、但却无法给出让用户选择NoSQL的真正有说服力的理由。SaaS应用程序其实基本不可能彻底摆脱与关系数据的交集。在这种情况下，大家从RDBMS系统当中获得的功能特性要远远胜过NoSQL系统。笔者认为NoSQL引擎现在需要高度关注那些过去被严重忽略的层面与问题。尽管目前充斥着大量NoSQL能够为关系型应用程序带来突出性能表现的宣传，但实际效果恐怕还要让各位用户亲身验证。能够切实从NoSQL身上受益的应用程序在数量上明显少于能够从SQL身上受益的应用。一旦宣传炒作风头渐消、NoSQL引擎的数量也降低到合理的水平，笔者认为到那时NoSQL才会真正在特定场景中成为一款优秀的工具。笔者还认为，NoSQL未来更可能成为SQL系统的一种有效补充而非替代方案。就目前而言，笔者将继续坚持自己的SQL路线不动摇。
原文链接：
http://www.itworld.com/big-data/428717/nosql-no-go-once-again?source=ITWNLE_nlt_tonight_2014-07-25
原文标题：NoSQL is a No Go Once Again
