想用数据库，我们该选关系型还是NoSQL？曾几何时，二者之间还存在着明显的差异，但随着近年来一系列关系型数据库中对JSON支持能力的引入，原本明确的边界开始变得愈发模糊。

但纳入JSON支持能力不是应该让RDBMS拥有更为雄厚的竞争资本，从而与NoSQL展开更加激烈的市场对抗么？话是没错，但从长远角度看却并非如此。关系型数据库与NoSQL产品之间的真正差异仍然深在root与core层面，而且二者绝不可能因此而“攻守之势异也”，即Oracle没办法凭借着JSON支持转型、Hadoop也绝不会借助SQL查询而倒戈。

JSON并不是问题的关键

首先，JSON支持能力本身并不是决定一款数据库产品应否属于NoSQL阵营的标准。AdRem软件公司的Tomasz Kunicki（曾创造出NetCrunch监控系统，其中使用了内存内、SQL以及NoSQL等多种技术）赞同道：“JSON本身其实决定不了什么。它只是一种更为便捷的数据表示方式，特别是在大家利用JavaScript编写代码的场景之下。”

根据Kunicki的意见，NoSQL类方案的真正核心在于其“无模式数据库与可扩展能力——但与大多数人的印象相左，这并不意味着NoSQL不需要数据库建模。”他同时指出，这种误解引发了关于NoSQL技术的大量不切实际宣传与滥用。事实上，此类方案“特别适用于以时间为基础的数据（且这些数据由该应用程序生成）处理场景”。

作为长期效力于微软公司的老员工兼Snowflake数据仓库即服务方案的联合***之一，Bob Muglia认为关系型与NoSQL数据库之间的本质差异在于二者在目标用途方面的设计思路。

Muglia指出，关系型数据库在创建过程中强调高度一致性，但同时以速度与规模作为妥协因素——至少以此构建起速度出色且规模庞大的数据库体系需要付出高昂的成本并面临一系列难题。NoSQL则在一定程度上牺牲了不同节点之间的一致性水平，但借上实现了理想的速度表现与可扩展能力。

但这并没有阻止人们尝试将NoSQL类型的速度与规模引入关系型数据库的野心，只不过通常而言这是一项极难完成的突破。“我们构建起Snowflake作为起点，并将MySQL作为原初系统来保存元数据，从而满足事务对于基于ACID数据的全面需求，”Muglia指出。“除了规模扩展，我们还需要实现理想的可用性水平，也就是五个九——要想在关系型数据库当中获得五个九级别的可用性表现几乎是痴人说梦……因此为了实现元数据存储，我们将其由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之外，目前还有包括Splice Machine（间接脱胎于Hadoop与Apache Derby项目）在内的一系列其它项目与产品正努力实现这项目标。

这一领域仍然处于起步阶段，但真正的下一代产品很可能正来源于那些积极甚至有些激进的实验性尝试，而非简单将数据格式或者查询系统等底层技术组件进行彼此互换。

英文：http://www.infoworld.com/article/2863018/nosql/watch-out-for-nosql-washing-in-your-rdbms.html