微信号:infoqchina

介绍:有内容的技术社区媒体

不要就这么放弃了SQL

2014-05-12 20:33 InfoQ

SQL这门语言已经稳定地发展了20多年。同时,Java客户端代码中冗长的JDBC API和Java语言缺乏一流的SQL 支持的情况,使得ORM开发框架开始渐渐占据一席之地,例如后来作为标准加入到JPA和Criteria API中的Hibernate。然而,出于性能上和表述上的考虑,一些用户还通过复杂的SQL查询语句和数据库进行交互 - 这种复杂性和JPA中所覆盖到的特性是相悖的。如果SQL和JPA越来越背离,我们的数据交互模式应该何去何从?


最近的TopConf 2013大会对我的影响

软件大会是我们行业在未来的5到10年将如何进展的新趋势和新思维的指向标。Topconf是一场在美丽的爱沙尼亚,塔林新举办的令人期待的大会,相当多的技术演讲都是关于大规模、分布式数据处理,以及新兴的技术和范例。第二天的开场主题演讲是由GridGain 公司的创始人和CEONikita Ivanov所做的一场关于记忆体内运算方面的演讲。之后不久来自Hazelcast的Christoph Engelbert 举办了一个比赛演讲,不少的演讲都是关于异步编程和响应式编程,后者是一种新兴的范式,起源于Scala的 “subculture”,通过共用服务器上的可计算资源,来处理水平伸缩的情况。


无论何时,只要“垂直伸缩”和“水平伸缩”这样时髦的名词出现,一些广为人知的NoSQL制造者名字,比如MongoDB 或者Cloudera(Hadoop)也会跟随出现。这样的情况一直到2013年5月,MongoDB 被估值1.2亿。Nikita Ivanov和ChristophEngelbert都提到了一个很好的观点,当我们在考虑伸缩问题的时候,这一观点将对我们的想法起到更真实和实际的影响。


垂直伸缩还是水平伸缩?集中化还是分布式?

首先,DRAM的价格在过去几年飞速下跌,你都不敢想象十年前的记忆体内计算(那时候大概1美元/MB),而现在很多公司有能力把他们所有的在线交易数据全放到内存中(大概1美元/GB)。就像 Nikita说的,99%的公司都没有9TB大的在线数据量,这是在可支持的范围内的。这就允许把大量的数据从磁盘中(毫秒级别的访问)转移到内存中(纳秒级别的访问),而不用实际上改变软件架构!换句话来说,不需要使用什么新奇的技术,就可以使遗留系统得到量级的提速。这对正在从COBOL 迁移至Java,而又不太情愿替换关系数据库的大公司非常重要。再换句话来说,也许实际上我们并不需要新的数据存储范式。不是吗?


另一方面,数据量仍然在不断变得越来越大,而且人们想进行数据分片和数据分布式,物理上让数据更接近用户。即便是真的有这么一台可以计算的机器,可以迅速地处理越来越大的记忆体内计算,将巨大的数据通过网线传输,也会连续遇到网络延迟、包丢失和别的原因导致的性能问题等方面所造成的困扰。


Hazelcast实施了一种“新的”范式,即把计算转向数据,而不是把数据转向计算。这也是OLAP数据库一直以来长时间在做的事情。现代的 RDBMS 融入基于 SQL 的语言,在接近数据的位置执行存储过程,这种语言很复杂而且很具有表述力。实际上,这甚至很像早期的共享主机系统,比如 IBM 7094,那时候开发者在中央计算引擎上分享时间槽。所以这并不是新的范式。我们只是在体验分布式和集中化计算的周期振荡,基于可用的资源和这些资源的力量。如果说NoSQL是分布式的强大力量,那么下降的DRAM价格就是集中化的强大力量。


同时,企业级Java中发生了什么?

这些主题是怎么关联到最近Charles Humble在InfoQ 的调查,关于我们怎么在 Java 中访问关系数据库的呢?根据他和 Martin Fowler 的观察,通常,人们似乎对ORM变得越来越不满了。这些情感变化很大一部分是因为ORM会发生是一种泄漏的抽象(Leaky Abstractions)的这一事实。Joel Spolsky 很久之前就已经观察到了这一点。


最近JEE 7中的JPA 2.1标准升级引入了一些的功能,可以更好地和“高级”的数据库特性进行集成,例如存储过程。关系数据库变得更符合 SQL 的标准,这个标准在不断地朝无法用 JPA 表述的方向发展。通过ISO/IECSQL:1999 标准,我们可以利用分组集和(递归式的)通用表表达式。有了SQL:2003标准,我们已经有了非常复杂的开窗函数和MERGE 语句。有了 SQL:2008标准,我们可以执行分段的 JOIN 语句。通过 SQL:2011标准,现在我们可以和临时数据库进行交互操作(现在IBM DB2和Oracle都已实现)。上述这些特色没有一个在JPA中或者别的大多数Charles Humble所列举的ORM 中有所体现,除了 jOOQ,这是Java建模SQL中一种类型安全的内部领域特定语言(在Topconf大会上也有相关主题的演讲)。


也就是说,当数据管理市场以快速的步伐扩大的时候,企业级Java社区还在慢慢地以小版本号的幅度更新着持久化API。


未来会发生什么?

我们可以说的是,在未来几年软件技术会快速地变化。以下是一些将会被质疑的范式:


数据存储

RDBMS已经很好地服务于我们,并且在将来继续很好地服务于我们。它们的创建基于很复杂的和很可靠的理论——关系理论,这种模型能够适用于许多问题的解决。


其它的类型的数据存储则会继续浮现,在非RDBMS市场中争夺新的优势。关于为什么应该选择别的数据存储而不是调整现有的,有两个基本的原因:

  • 对于高度层次型的或者非结构化的数据,关系数据模型不够用。

  • ACID不能满足极端的水平伸缩情况,网络潜在问题导致在分布式系统中所有的 A-C-I-D 都变成难以解决的问题。


但是,当说到集成列存储(也被称为 NewSQL),更多的像是让老象学习新技能,关系型数据库制造者最终也会集成经过验证的NoSQL功能。


语言

命令式(和面向对象)编程在最近几年,已经受到函数式编程极大的挑战。显著的挑战者有Scacla,Javascript,C#3.0,VB 9和 Java 8。一个简单的解释是,函数式编程让计算逻辑更加容易地接近数据。同时,产生的副作用是期望中的,这也被 Simon Peyton Jones 自己确认,当时他在和LINQ的创造者Erik Meijer讨论编程语言的未来。


另一方面,Erik Meijer创造的 LINQ 的人气,已经证明声明式查询语言是复杂的数据库交互的一种好范式。SQL 本身在之前提到的多样的新标准上不断提升。眼下,Facebook 已经开源了他们自己的ANSI-SQL,它是建立在 Apache Hadoop 之上的,基于自己编写的查询语言。


可以说的是,这些语言范式中没有一个可以被别的所替代。


SQL 无所不在

在数据处理上SQL无所不在,这让我们更加了解到为什么Charles Humble发现,在使用类似Hibernate这样传统的ORM时,会让人越来越不爽的重要原因。这些工具已经解决了以下两个问题:

  • CRUD的重复性

  • 缓存,可以提高磁盘访问速度。

智能缓存是很困难的,即便是实现了很多实体级别的SQL缓存功能的 Hibernate。Hibernate或者JPA的缓存机制之所以能够现实,是因为ORM策略已经深深地和JPQL集成。由于缺乏原生查询功能,很难绕过缓存的核心机制。


但是别忘了内存变得多么的便宜?缓存大多数数据可以保证很少量地访问磁盘。如果数据不再从磁盘上访问(毫秒级),而是从内存中访问(纳秒级)会怎么样?当数据库已经把所有相关的数据缓存到内存中,我们依然需要完整的和复杂的二级缓存吗?


数据库不仅有能力把在线交易数据一直放在内存中,而且它们早就可以实现一些复杂的缓存机制了。想想 Oracle 的游标缓存,查询结果缓存,和标量子查询缓存吧。


虽然JPA依然是CRUD操作的优秀工具,但以SQL为中心的工具正在被越来越多的人选择使用,比如:MyBatis 或者 jOOQ(都是“后JPA 框架”)表明了一种需要再次更加接近SQL的确定需求。ANSI-SQL标准不断发展,把不断革新的数据库的各种功能进行标准化,比如:Oracle,SQL Server,PostgreSQL,通常是那些很难集成到JCP甚至是今后的JPA版本中的一些特性。JPA 2.1 支持存储过程,但是在客户端代码管理的这些支持,看起来和在 JDBC 中实现的可调用语句(CallableStatements)一样单调乏味。另外,JPA 2.1虽然有了各种新的与存储过程相关的注解,但并没有把嵌入式的用户自定义函数加入到SQL语句中,而这些却被不知名的CriteriaQuery API不充分的表述出来。大会上的所有关于 jOOQ 演讲,我都在问观众他们使用 CriteriaQuery 幸福吗。他们的回答是一致的不幸福。


总结

时光的列车辙辗而过。RDBMS仍旧在不断发展和拥抱新的功能,按照ANSI SQL进行自我标准化,并逐渐放弃 JPA 2.x。在这几次变化中,JPA规范看起来局限了数据存储市场进行的革新。EclipseLink最近通过JPA扩展支持MongoDB,表明了标准制定者并不确定他们将走向何方。


但是有一件事情是确定的。我们不会这么快放弃SQL。那么为什么不再次拥抱它?


***********************************

本文来自InfoQ微信公众账号:infoqchina

1、回复“今日新闻”,查看今天更新的新闻;

2、回复“今日英文”,查看今天英文站的更新;

3、回复“文章 +关键词”,搜索关键词相关内容;

4、回复“QCon”,了解QCon大会相关信息;

5、回复“活动”,了解最近InfoQ组织的线下沙龙;

6、回复“架构师”,获取《架构师》下载地址;

7、回复“投稿”,了解投稿和加入编辑团队的流程。

***********************************


 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 飞行的架构师和奔跑的程序员 金庸笔下的“程序员” 「牛人大讲堂」第三期:《大型网站架构的发展与变迁》 假如程序员生活在童话里...... 【里约奥运专题】哪些内容不可错过?