想用数据库，选择关系型还是NoSQL？曾几何时，两者之间有着明显的区别，但随着近年来一系列关系型数据库引入JSON支持，原本清晰的界限开始变得越来越模糊。但是加入JSON支持能力不应该让RDBMS拥有更强的竞争资本，从而与NoSQL展开更激烈的市场交锋吗？确实如此，但从长远来看并非如此。关系型数据库和NoSQL产品真正的区别还在根和核心层面，两者不可能因此而“攻守不一”，即Oracle不支持与JSON的转换，以及Hadoop永远不会在SQL查询的帮助下扭转局势。JSON不是问题的关键首先，JSON支持能力本身并不是决定一个数据库产品是否应该属于NoSQL阵营的标准。AdRemSoftware的TomaszKunicki（使用内存中、SQL和NoSQL的NetCrunch监控系统的创建者）同意：“JSON本身并不能真正确定任何事情。它只是表示数据的一种更方便的方式。”，尤其是当人们用JavaScript编写代码时。”根据Kunicki的说法，类NoSQL解决方案的真正核心在于它们的“无模式数据库和可扩展性——但是，与大多数人的想法相反，这并不意味着NoSQL不需要数据库建模。”他还指出，这种误解导致了很多不切实际的宣传和对NoSQL技术的滥用。事实上，此类方案“特别适合处理应用程序生成的基于时间的数据”。BobMuglia作为微软的长期元老，也是Snowflake数据仓库即服务解决方案的联合负责人之一，BobMuglia认为关系型数据库和NoSQL数据库的本质区别在于两者的设计思路在目标用法。Muglia指出，关系型数据库在创建过程中强调高一致性，但同时又以速度和规模作为折中因素——至少这样看来，构建速度极佳、规模庞大的数据库系统需要高昂的成本和面子一系列困难。NoSQL在一定程度上牺牲了不同节点之间的一致性水平，但获得了理想的速度性能和可扩展性。但这并没有阻止人们尝试将NoSQL式的速度和规模带到关系数据库中，这通常是一个非常困难的突破。Muglia指出：“我们以Snowflake为起点，以MySQL作为存储元数据的源系统，以满足交易对基于ACID的数据的综合需求。”“除了扩展之外，我们还需要达到理想的可用性水平，即五个九——在关系型数据库中几乎不可能达到五个九……所以为了实现元数据存储，我们将一直从MySQL迁移到基于ACID的NoSQL系统FoundationDB。”加入了SQL查询机制的NoSQL存储系统还是NoSQL。为关系数据库添加JSON支持能力不会使其成为NoSQL系统。反之，SQL将查询机制融入到NoSQL存储系统中，永远不会把它变成关系型数据库——两者甚至没有竞争力。使用SQL查询NoSQL存储内容可以为用户带来极大的便利，而且内部无需重新定义SQL（或NoSQL）的操作。正如Muglia所指出的，由于SQL定位为查询系统，已经有一种趋势将SQL引入到分析系统中，“不管它包含什么影响因素”（即运行在什么样的机制中）深层），由此产生的结果是从SQL到事务系统的转变，“至少在高可扩展性和高可用性方面是这样。”Kunicki认为，必须承认和尊重不同数据库系统之间的内在差异。“将SQL添加到NoSQL数据库中，”他说，“并将对JSON文件的支持添加到SQL数据库中，只是一种试图欺骗用户的肤浅方式。”结合大型数据库（ACID事务）和NoSQL（速度和可扩展性）优势的可行性和重要性。除了FoundationDB之外，目前还有许多其他项目和产品正在朝着这个目标努力，包括SpliceMachine（间接源自Hadoop和ApacheDerby项目）。这个领域还处于起步阶段，但真正的下一代产品很可能来自于那些积极的、甚至是一些激进的实验尝试，而不是简单地相互交换数据格式或查询系统等低级技术组件。英文：http://www.infoworld.com/article/2863018/nosql/watch-out-for-nosql-washing-in-your-rdbms.html
