为什么说关系型数据库不会灭亡

过去十年是非常令人兴奋的十年，因为它与数据有关。在这十年中，一些技术的出现见证了数据的爆炸式增长：

社交媒体(或者说Web 2.0)产生了持续增长的数据;

物联网(传感器设备)产生了日益增长的数据;

新模型不断涌现出来，数据库市场从没如此热闹过。

厂商市场人员，分析师机构和媒体以及技术传播者们创造了“大数据”和“NoSQL”这些词汇，把过去十年里围绕持久化技术出现的模糊观点汇集在一起。然而多大才算“大数据”呢?你做的是“大数据”吗?你需要“大数据”吗?这些根本性问题却很少有人提起。

事实上，你真的不需要。你可以继续使用传统的架构和关系型数据库。我坚信关系型数据库不会灭亡。为什么?且看我总结出的三大理由：

1、RAM的价格持续走低

一时之间，经济学家和分析师都认为摩尔定律将要终结。单CPU的处理能力达到了非量子物理所能达到的极限，我们不能再以那么低的成扩展处理器能力。因此多核处理器出现了，厂商都开始鼓吹采用分布式架构来进行数据处理和共享。

但是我们真的需要把数据分发到多台服务器上，并在分布式环境中与CAP理论做斗争吗?事实上，你大可不必付此代价。(注：CAP原则是NOSQL数据库的基石。Consistency一致性、Availability可用性、Partition tolerance分区容错性。)

虽然CPU不会变的更快，但是RAM却一直在变的更便宜。现在，一台数据库服务器可以把整个数据库都放到内存中，这个费用我们是绝对负担得起的。

几家主流的关系数据库厂商已经基于其各自的标准产品实现了内存计算功能和列存储功能。包括Oracle数据库12c、SQL Server 2014、SAP HANA等。全球最大的问答网站Stack Exchange就是一个很好的例子，到目前为止，他们还在使用集中式的RDBMS来跑核心应用。他们的服务器配置了400GB RAM，每天要处理3.43亿次查询操作，运转起来没有遇到任何问题。

这种经典架构很好地印证了遵循摩尔定律：“只要扔更多的硬件进去，它就能更快地运行。”所以你还没有必要把系统改造成分布式架构。换句话说，磁盘已经不在是应用程序的性能瓶颈。有了RAM，你可以很容易地在单一服务器上进行扩展。

2、SQL是最好的查询语言

你可以说SQL时最差的数据库查询语言，但你也找不到第二种语言来代替它。

从技术的角度来看，QUEL可能曾经是更好的语言，但是80年代初期由于Oracle和IBM耍了花招，SQL以及ANSI/ISO SQL标准最终胜出了。SQL最基本的广受批评的问题之一是它并不是真正的关系型语言。这一点早在1983年C.J.Date就在其论文《对SQL数据库语言的批判》中就明确指出了，但是那时已经太迟了，SQL已经赢得了竞争。为什么呢?

(注：Ingres 公司使用的是 Stonebraker 教授发明的QUEL的查询技术，这和IBM的SQL大不相同。在某些地方QUEL甚至要优于SQL。IBM当时担心Ingres把QUEL变成标准会对自己不利。经过一番衡量，决定把自己的SQL提交给数据库标准委员会。而Stonebraker教授可不打算把QUEL提交给数据库标准委员会，学院派的他认为这么做实际上是扼杀了创新精神。鹬蚌相争，渔翁得利。ORACLE看到并抓住了这个绝佳的机会，大肆宣布ORACLE全面与SQL兼容，加上 ORACLE当时对Ingres PC上的版本的攻击，再加上ORACLE公司销售上的强势，Ingres不断丢城失地，等到后来推出支持SQL的数据库的时候为时已晚。紧跟IBM让 ORACLE得以成长、壮大，拥抱标准，拥抱开放，拥抱变化，让ORACLE立于不败之地。——Fenng《书写历史的甲骨文–ORACLE公司传奇》)

SQL本身就是设计用来让人类创建临时查询的语言。值得注意的是，SQL语言几乎是唯一的声明性语言，它存活了下来并成为了最流行的数据库查询语言。

在大部分人们还更适应以命令行的风格指挥计算机工作时，声明式思想是很难被接收的。我们可以看到，试图创建这类语言的不只在数据库领域，也包括一些常规用途语言(比如：Java语言)。具体来说，Java EE完全是标记式的，主要标记标签和成员类型，使解释器可以处理那些标签并注入行为。一旦你把JPA，JAXB，JAX-RS，JAX-WS，EJB，甚至或许还包括Spring和一些其他工具组合到一起形成应用，你马上就能知道理解所有这些声明式元素的含义以及了解它们如何及何时交互有多么困难。通常情况下，行为不是具体的或者是半具体的。

SQL是一种比较简单的声明式语言，有很多的限制。这是优点，因为语言特性不多，可以使你快速实现符合SQL标准的需求。事实上，SQL语言的这种普遍性甚至导致了许多NoSQL数据库都在采用SQL或者非常近似地模仿SQL：

SQL on Hadoop

Phoenix for HBase

Cassandra的CQL

JCR-SQL2等等

当然了，更不用说数不清的关系型数据库统统都在使用SQL。

随着广受欢迎的ORM帮助把用SQL实现CRUD的繁琐工作抽象出来，再考虑到查询和大批量数据处理(不管你的底层存储是关系型的还是非关系型的都没有关系)，可以说SQL几乎没有有竞争力的替代品。

换言之，SQL的非关系性是该语言的主要优点之一，它使得SQL可以与其它方面的数据处理进行协作，比如XML、OLAP、JSON、列存储等等。

3、过程性语言是理想的计算机语言

关系型数据库胜过其它非关系存储机制的第三个优点就是过程性语言(Procedural Language)与SQL语言的紧密集成。
如果你采用纵向扩展，那么你的单台数据库服务器会希望利用尽可能多的处理器核心资源。因此，你会希望尽可能在服务器的RAM中进行数据计算。

多年来，企业软件架构师们都在试图把业务逻辑转移到中间层，对于采用J2EE或者后来的Java EE架构的更是如此。这一观念帮助许多大型软件厂商在已经销售了昂贵数据库的情况下，又成功销售了及其昂贵的中间件作为架构必备补充。

在以前这是非常合理的，因为20年前的数据库并没有当今数据库如此强大。然而，现在商业版的SQL优化器已经极其强大了。为让你的SQL提速，你需要做的全部工作就只有调整合适的索引了。如果你决定使用的平台不支持使用SQL，那么这会极大增加你的数据处理逻辑总拥有成本。要想手工操作，用Java这种通用的命令式语言以算法的形式实现执行计划调优是非常困难的。当然，这种做法也有一些思路，可以用像jOOQ这种API实现。

对于一切不合适用SQL的情况，你可以使用关系数据库的过程性语言，它支持直接在数据库中实现更复杂更明确的算法，可以使业务逻辑与数据绑定非常紧密。这种语言不但访问数据非常快速，而且可以用SQL与大批量数据处理交互。

换句话说，把一些计算量繁重的逻辑放到数据库中，对于许多情况来说都是最好的选择。我认为未来会有更多的技术公司将开始构建内存数据库，这将毫无疑问进一步推动过程性SQL语言的普及。过程性语言包括：Transact-SQL(T-SQL)，PL/SQL和SQLScript。

关系数据库赢得了过去，也将赢得未来

“如果你只有一把锤子，那么所有问题看起来都像钉子。”

对于关系数据库来说，可能没有更好的比喻了。他们是瑞士军刀级的锤子，有数以百万计的工具，绝大多数开发者们需要的只是这把“锤子”，他们就可以走很远。所以，保持冷静，继续前行(Keep calm and SQL on)!