Alibaba 蚂蚁自研数据库OceanBase登顶TPC-H榜单,核心成员撰文讲述背后思考( 二 )


天下大事,分久必合,合久必分 。HTAP本来也不能算是新概念 。TP和AP这两种需求在数据库的发展上已经历了漫长的混合-分离-再融合过程 。
上世纪70年代末到90年代初是数据库从理论到实践逐渐成熟的黄金时代 。1970年,IBM的E. F. Codd提出了“关系型数据库”的概念 。1974年,IBM着手研发System R数据库,极大地推动了关系型数据库概念的发展,并采用SQL作为标准的数据库语言 。
70年代末到80年代初,有“数据库先生”之称的图灵奖获得者Jim Gray奠定了事务处理的理论基础 。同一时期,System R系统的实现也催生了查询优化技术 。Selinger等人发表的“Access Path Selection in a Relational Database Management System”论文则被认为是基于代价的查询优化技术的开山之作 。1988年,IBM的Barry Devlin和Paul Murphy提出了专门用来做数据分析的“数据仓库”(以下简称“数仓”)概念 。1993年,E. F. Codd仿照“On-line Transaction Processing”的结构首次提出了“On-line Analytical Processing”的概念,一下子把数据分析的抽象和应用提升到了一个新的层面 。可以说,在数据库远古大神一个个粉墨登场的年代,TP和AP两种场景就像一对被他们细心呵护的孪生兄弟茁壮地成长着 。
随着数据库使用场景的日益丰富,TP和AP需求的矛盾逐渐显露 。单机数据库的处理能力毕竟有限,分布式数据库的理论开始出现,工程实践也遇到很多问题 。
怎么同时处理TP和AP请求?1988年 提出的“数仓”概念,背后隐藏的假设是TP和AP请求会放在不同的系统中处理 。这样假设有业务发展和应用架构的必然性,但技术层面的限制也是不可回避的问题 。毕竟在那个时代,作为分布式数据库系统的TerADATA,最大只能支持1000个核和5TB存储 。而且,真正能够使用这样高端系统的用户寥寥无几 。
当用户开始被迫地把TP或者是AP的请求分成不同系统时,专门处理TP和AP场景的数据库随之出现 。针对不同场景,采用不同引擎技术,比如按行存储或是按列存储,确实能够大幅度提高特定场景下的数据库性能 。
但不可否认,一个能同时处理TP和AP请求的数据库,对于用户来说是非常有价值的,除了能大幅度降低用户成本外,还能明显降低用户系统的复杂性和运维成本 。
因此,很多成熟的商业数据库,如Oracle、IBM DB2等,在保持极强的TP处理能力之外,从来没有停止过对AP场景的支持和优化 。如果大家看一下这些数据库巨头在顶级学术会议上发表的论文列表就会发现,面向AP场景的论文,数量甚至比事务处理方向的还多,而且每年都有更新 。
2010年前后,随着硬件能力越来越强,尤其是SSD固态盘、大容量内存和多核CPU等技术的普及,大大增加了数据库的设计可能,促使不少数据库研究人员重新思考在同一个数据库中处理TP和AP请求的可能,甚至包括当初缔造“数仓”概念的Barry Devlin都提出,应该“重新考虑将TP和AP分开这一设计理念” 。今天,不少新的数据库也开始宣称支持HTAP,我想也是顺应了整个技术的大趋势 。
二、OceanBase 把HTAP写入基因
OceanBase是2010年开始在阿里集团内部自主研发的分布式数据库 。最开始基本就是在阿里、蚂蚁内部用,真正长得像一个数据库的样子,应该是从2014年启动OceanBase 1.0版本开始的 。我也是在那个时候加入OceanBase,跟着团队一步步走到了今天 。
Alibaba 蚂蚁自研数据库OceanBase登顶TPC-H榜单,核心成员撰文讲述背后思考
文章图片

回想当初,数据库的很多技术都在悄悄发生着变化 。一方面,以Oracle为首的传统数据库在TP场景似乎已经“独孤求败“,TPC-C世界纪录已经多年未被打破,而像OceanBase这样的分布式数据库还没有看到挑战Oracle霸主地位的可能 。
另外一方面,传统数据库的AP能力越来越跟不上数据规模和硬件的发展 。SSD、大容量内存、超高核数的CPU,这些理论上能带来巨大性能提升的硬件无一不在挑战传统的数据库软件设计 。TPC-H榜单上,Oracle、SQL Server这种传统数据库被神秘的数据库厂商Exasol虐的找不着北 。Exasol具体怎么实现的我不是特别清楚,但向量化引擎、cache-aware、列存、及时编译(Just-in-Time compilation),大致总离不开这几个方向 。但传统数据库不是这么设计的,内存能大到几百GB甚至上TB?最初的数据库设计者想都不敢想,更别提充分利用了,“守着金山要饭吃”,当时的传统数据库看到硬件的发展就是这么一种感觉吧 。
当时的我也在思考这个问题:一个能同时处理好TP和AP请求、并且能充分挖掘硬件能力的数据库到底应该是什么样的?“缝缝补补带不来真正的技术革新” 。在一个现成的开源组件去打补丁,或者简单重构很难做出一个划时代的产品,因为我自己曾在一个面向AP的开源引擎上尝试过这件事儿,干到后面觉得比重写一个引擎难多了 。2014年OceanBase 1.0版本正在酝酿中,对我来说,做一个真正HTAP引擎的机会来了 。

推荐阅读