OceanBase 再破纪录!核心成员陈萌萌:坚持 HTAP 就是坚持我们做数据库的初心-阿里云开发者社区

开发者社区> OB数据库> 正文

OceanBase 再破纪录!核心成员陈萌萌:坚持 HTAP 就是坚持我们做数据库的初心

简介: 解构技术背后的思考,一起加速奔跑!
+关注继续查看

写在前面的话

2021年5月20日,据国际事务处理性能委员会(TPC,Transaction Processing Performance Council)官网披露,蚂蚁集团自主研发的分布式关系型数据库OceanBase在数据分析型基准测试(TPC-H)中,以1526万QphH的性能总分创造了新的世界纪录。

1.jpg

同时,OceanBase 也成为唯一在事务处理和数据分析两个领域测试中都获得过世界第一的中国自研数据库。

我们特别邀请到 OceanBase 负责此次测试的核心成员陈萌萌撰文,讲述背后的技术思考。

以下为陈萌萌的自述

收到期盼了好几天的审计员最终邮件,告知测试结果已经挂到了官方网站。这意味着,测试小组的工作可以正式告一段落。接下来的60天,此次测试的报告将处于公示阶段,迎接全世界数据库专家的检视和挑战。

对我个人来说,原本期待的兴奋感没有如期而至。更多的是平静。平静地把官网上的测试报告又从头到尾读了一遍。按说,前前后后来来回回几十封邮件的技术沟通,报告里面的内容已经烂熟。再读一次,既是出于技术人天生的谨慎,更是不想因为一个低级错误而让项目所有同学三个月的心血付诸东流。

关于为什么要冲击此次的榜单?简单来说,是因为今天的 OceanBase 已经升级为一款支持 HTAP 混合负载的企业级分布式数据库,同时具备事务处理和数据分析两类场景的处理能力。我们希望市场对我们有更多了解。权威中立机构的背书总好过“王婆卖瓜自卖自夸”。此外,从技术上说,这也是一件水到渠成的事情。只是,这个时间点跟 OceanBase 对数据库的理解,以及未来想做的事情有密切关系。

01

HTAP,既是数据库的初心,也是数据库的未来

HTAP数据库(Hybrid Transaction and Analytical Processing,混合事务和分析处理)就是能够将事务处理(On-Line Transactional Processing,以下简称TP) 和数据分析 (On-Line Analytical Processing,以下简称AP) 请求在同一个数据库系统中完成。

这个概念,由Gartner在2014年的一份报告中提出。分析师认为,这种架构具有显而易见的优势:不但避免了繁琐且昂贵的ETL操作,而且可以更快地对最新数据进行分析。这种快速分析数据的能力将成为未来企业的核心竞争力之一。

关系型数据库的英文缩写是RDBMS,其中的M就是“管理”的意思,不管是TP还是AP,数据库的存在就是为了“管理”数据,我认为这是数据库这个系统的初心。

天下大事,分久必合,合久必分。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,我想也是顺应了整个技术的大趋势。

02

OceanBase 把 HTAP 写入基因

OceanBase 是2010年开始在阿里集团内部自主研发的分布式数据库。最开始基本就是在阿里、蚂蚁内部用,真正长得像一个数据库的样子,应该是从2014年启动OceanBase 1.0版本开始的。我也是在那个时候加入 OceanBase,跟着团队一步步走到了今天。

回想当初,数据库的很多技术都在悄悄发生着变化。一方面,以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引擎的机会来了。

从时间上看,AP场景的几项关键技术是随着产品丰富逐步完善起来的。2014年做了基于代价的查询优化器。2016年做了分布式运行一体化执行。2019年和2020年分别做了向量化执行引擎和TP、AP的资源隔离。事实上,这些年,OceanBase 的AP能力一直在不断增强,只不过大家很少有机会了解。

如果知道这些来龙去脉,大家对 OceanBase 冲击TPC-H这件事儿,也许就没那么奇怪了。今天我们的用户场景和产品定位也都需要产品具备这样的能力,从这个角度上讲,OceanBase 正式进入到HTAP产品时代,也是市场的选择。

从2017年开始,我每年都会投入相当比例的时间拜访外部客户。在这个过程中,深刻感受到,对于HTAP,不同客户有不一样的认知。

其中一部分用户使用的是典型的TP、AP独立架构。这类用户以互联网公司居多,受目前流行的解决方案影响。系统设计之初就将TP和AP系统分开,通过中间链路同步数据。这类用户一般有两个痛点,一个是实时性要求高的分析逻辑无法在TP数据库中原地完成,只能等数据同步到AP数据库中再做。另外就是系统难以运维,尤其是中小型的客户,运维人员得熟悉两套系统,还要时刻关注中间数据链路的稳定性,技术门槛很高。

另外一部分用户,一直使用的是像Oracle这样的传统的数据库,对于TP和AP的边界认知比较模糊,尤其是Oracle的处理能力很强,很多复杂查询扔到Oracle里面也能跑。在一次某大型客户的业务上线过程中,压测的最后阶段,我们发现了非常多的复杂查询。当我们询问客户为什么他们的TP系统中会有如此多AP请求时,客户的一句话把我们问懵了——“啥叫TP、AP请求?”我们在内部也有过讨论,发现即使是团队内部大家的看法也是不一样的。只能说有一些场景偏TP类型或者偏AP类型,但很难给出绝对答案。

越来越多的客户案例让我意识到,过去一直坚持的HTAP技术方向也是很多客户需要的。但今天在很多客户眼中,OceanBase 就是只支持TP处理的数据库,完全没想到我们还有很强的AP处理能力。“酒香也怕巷子深”,我们觉得这个时候打榜TPC-H,既能让产品的能力进一步提高,大家也能更了解 OceanBase 的价值。

03

TPC-H 新世界纪录背后的“三座大山”

如果让2014年的我说 OceanBase 什么时候能够在TPC-C、TPC-H这样的榜单上露个脸,我还真不知道。

做数据库就像盖房子,今天 OceanBase 这座房子已经到了交付阶段,要给客户的体验是“拎包入住”,因此水、电、装修风格都要做好。而2014 年就像在“打地基”的阶段,你说我将来要做某某内饰风格,至少当时没有想到那么具体的事情,但是我知道分布式一定是这个房子的“地基”,我们要盖的是一个摩天大楼,而不是一个独门小院。这个是打破传统数据库设计限制的前提,想通了这个事儿,后面的技术落地就比较自然了。

为什么分布式数据库是HTAP技术的未来?这个和HTAP的几大技术挑战有关。

首先,也是最重要的事情,这个系统的容量一定要足够大,扩展性足够强。

从数据容量上看,因为AP本身的分析要有价值,就需要聚集相当量的数据才有价值,这是以前的单机数据库做不到的。一台机器的容量,或者是几台机器的容量永远是受限的。十年前,世界上最大的Oracle RAC实际系统只有20来个节点。当时我在Oracle经历的一个重要项目是,将RAC的集群规模扩展到128台。而今天像 OceanBase 这样一个分布式数据库,做到几百台机器的集群规模是非常轻松的,这种规模上的区别带来技术上的想象空间是完全不同的。

而且在这次测试面向AP的场景中,又引入了一个 OceanBase 家族的新成员叫OceanBase File System(简称OFS)。这是一个分布式的共享存储系统,基于OFS的方案在存储容量上几乎是可以无限扩展,永远不用担心数据没地方存。这就解决了整个系统容量的扩展的问题。

另外,既然要将TP和AP放到同一个集群中处理,那么集群的处理能力也要有非常强的可扩展性。这里如果再讲多一些,处理能力的扩展性还能分为“水平”扩展和“垂直”扩展两个维度。

大家看过我们TPC-C的测试结果可能还有印象。当时,用了1554台机器,把整个TP系统跑这么高的分数。这个体现的是 OceanBase 的水平扩展能力。

什么叫垂直扩展性呢?就是在一台机器内部通过硬件扩展(更多CPU核数、更大内存)而提升性能。为什么这个在HTAP下仍然有挑战?因为在TPC-C的扩展里面,更强调的是水平扩展,换句话说,数据库集群规模越大,性能分数就越高。但在AP场景下,用户同时也会关心能不能实现垂直扩展,比如说能不能让一个系统的几千个CPU核,几十台机器同时为一个查询服务。万事万物,只要涉及到“协同“,就有成本。把协同的成本降低到最低,考验的是系统整体的设计。

TPC-H测试场景中,要求我们用64台机器的5120个CPU超线程,同时去服务每一个用户请求,把本来需要几十分钟才能完成的请求,在几秒内处理掉,这里涉及的CPU核数和整体性能数值都是整个TPC-H结果中最高的。

第二个方面是一个真正的HTAP系统需要在TP场景和AP场景都有很强的处理能力。

OceanBase 的TP处理能力在TPC-C打榜过程中已经得到了验证,背后的技术也有相关文章详细解读,这里不再赘述。那AP场景到底要求的是什么能力?

首先来说是查询优化的能力。AP场景天然有很多复杂的用户查询,具体到SQL语句上就是大量的多表连接、复杂的表达式计算、多层嵌套的子查询、聚合函数等等,这些对引擎的查询优化能力要求门槛极高。

记得曾经一个同行半开玩笑的说,很多专注TP的数据库系统不是不想做HTAP,只是“没有时间好好写一个查询优化器”。OceanBase 的1.0版本,重点重构了整个优化器的架构,引入了几十种逻辑改写和基于代价的计划选择,没有这个基础,我们不可能跑出今天TPC-H的这个性能。

其次,执行引擎的设计要求与TP天然不同,AP系统要访问大量的数据,迭代数据的效率极为关键。这个领域也是近十年来数据库研究的重点,从“火山”模型到“数据流”模型、从“拉”数据到“推”数据、cache-aware、即时编译(Just-in-time compilation),各种技术令人眼花缭乱。

OceanBase 的最新3.0版本引擎与之前的最大不同在于引入了新的cache-aware向量化处理,在大数据量场景下有数倍的性能提升。当然,我们还要清醒的看到,OceanBase 的引擎性能距离很多优秀产品还有明显的差距,这个方向的工作才刚起步。

第三个挑战,在于HTAP里面的H,Hybrid,混合。AP和TP是技术要求上天然不同的两类请求,典型的TP的场景是简单请求、小数据量、高并发,关注重点在系统的吞吐量。

而AP场景则是复杂查询居多,运行时间长,更多关注响应延迟。这就像是田径项目中的短跑和长跑,对运动员肌肉类型、反应速度、耐力都有不一样的要求。一个好的HTAP系统,能在一个系统里把很多TP、AP的请求同时解决掉,就相当于在培养一个运动员,既能跑一百米的短跑,又能跑一万米或者是马拉松。好比博尔特,100米短跑的王者,但今天还要博尔特跑进一万米的世界决赛,难度可想而知。

因此,考验一个HTAP系统,往往不是一个单一的维度,而是看如何在去做技术的妥协,这个是考验我们整个技术的能力。OceanBase 今天已经应用在很多TP为主的核心场景,我希望做到的是AP能力的尽量能的延伸,我们今天在TPC-H测试中做了很多优化,但我们在TP场景的性能并没有出现回退。

另外,一旦将TP和AP的请求放在了同一个系统,意味着系统对于不同请求的资源使用要非常“合理”并且尽量互不影响。困扰数据库开发人员的一个难题是,当TP和AP请求混布时,两者之间的互相影响很难被“隔离”,今天“隔离”问题仍然是影响用户选择HTAP系统的一个重要挑战,我们将不同的资源在内部进行了虚拟化,并通过资源组的概念将TP、AP请求进行隔离,一定程度上解决了这个问题,但HTAP如何彻底的解决这些问题,还有很多有待探索的空间。

类似的问题还有很多,限于篇幅,只能先说这么多。但我认为任何一个真正的HTAP数据库,至少要能够比较好的解决上面提到的三个方面的挑战。

04

HTAP 的边界在哪里?

未来 OceanBase 的方向在哪里?

过去大家提到 OceanBase,第一反应就是一个典型的TP处理系统,具有很强的高可用和线性扩展的能力。TPC-H成绩出来以后,身边的很多朋友都想了解未来 OceanBase 会成为一款什么样的数据库产品?对这个问题,我有几点想法想和同行、客户分享。

首先,一个既能处理TP又能处理AP的数据库系统,可以大大简化系统的复杂性,是有不可否认的客户价值的,这点是HTAP产品的立足之本,也是我们做产品的初心。

因此,一个HTAP系统如果本身的处理能力不足或者使用起来很复杂,也是不能满足用户期待的,OB过去两年一直在尝试降低用户的使用成本,就是希望不管是大型客户还是中小型客户,是金融客户还是非金融客户,都能用的起,用的简单,甚至用的爽,这个方向很关键,未来也会继续坚持下去。

其次,每款HTAP产品都有自己的定位。OceanBase 起步于企业核心场景的分布式数据库,TP场景的处理能力将永远是 OceanBase 坚持的底线和优化方向。换句话说,我们不会以牺牲TP场景的能力为手段,提升AP场景的处理能力,这和很多以AP为核心场景的产品定位会有所不同。最后,HTAP是一种技术架构选择。

就像Gartner提到的:

Hybrid Transaction/Analytical Processing (HTAP) is an emerging application architecture that breaks the wall between transaction processing and analytics. It enables more informed and in business real time decision making.

说到底,HTAP架构是希望通过打破TP和AP的边界,最终带给客户实实在在的商业价值。对于 OceanBase 这样一款数据库产品,选择HTAP这样的技术方向意味着要克服更多困难。路还很长,好在11岁的 OceanBase 还很年轻,还有很多机会,很多希望。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
从Hadoop框架与MapReduce模式中谈海量数据处理(含淘宝技术架构)
 文章转载自: http://blog.csdn.net/v_july_v/article/details/670407 从hadoop框架与MapReduce模式中谈海量数据处理 前言     几周前,当我最初听到,以致后来初次接触Hadoop与MapReduce这两个东西,我便稍显兴奋,觉得它们很是神秘,而神秘的东西常能勾起我的兴趣,在看过介绍它们的文章或论文之后,觉得Hadoop是一项富有趣味和挑战性的技术,且它还牵扯到了一个我更加感兴趣的话题:海量数据处理。
1354 0
C++第4周(春)项目4 数组作数据成员
课程首页在:http://blog.csdn.net/sxhelijian/article/details/11890759,内有完整教学方案及资源链接 【项目4 - 数组作数据成员】阅读教材P255例8.4,注意到类中的数据成员可以是数组。设计一个工资类(Salary),其中的数据成员如下类的声明。 class Salary { public: void set
917 0
C++实践参考:数组作数据成员
【项目 - 数组作数据成员】下面是设计好的一个工资类(Salary): class Salary { public: void set_salarys( );//输入职工工资(输入-1标志着工资输入结束),工资保存到salary数组中,实际人数保存到number中; void add_salarys(int x); //给每个人涨x元工资
757 0
第7周-任务1-静态数据成员和静态成员函数
【题目】含有静态数据成员和成员函数的Time类:类中所有的对象共有的数据 class Time { public: Time(int=0,int=0,int=0); void show_time( );//根据is_24和from0,输出适合形式-20:23:5/8:23:5 pm/08:23:05 pm voidadd_seconds(int);
782 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
4398 0
阿里巴巴高级专家谭宇:云数据库OceanBase的架构演进及在金融核心系统中的实践
8月30-31日20:00-21:30,一场别开生面的技术大会—— “蚂蚁金服&阿里云在线金融技术峰会”将在线举办。本次将聚焦数据库、应用架构、移动开发、机器学习等热门领域,帮助金融业技术开发者深入解析互联网应用的前沿应用与技术实践。
6769 0
Mysql总结_02_mysql数据库忘记密码时如何修改
1.从cmd进入mysql的bin下,输入命令  mysqld --skip-grant-tables  回车      注:(输入命令前,确保在任务管理器中已没有mysql的进程在运行,可输入命令:net stop mysql  来关闭mysql服务,切忌此命令结尾没有分号) mysqld --skip-grant-tables的作用:跳过了mysql的用户验证   2.重开一个新的命令行,输入命令:mysql,连上数据库。
731 0
国内第一人:MariaDB基金会将阿里云数据库高级专家彭立勋列为个人成员
近日,MariaDB基金会把阿里云数据库专家彭立勋列为个人成员(Staff)。作为Mariadb高级开发人员,彭立勋将主要从事Replication模块的优化,同时他也致力于MariaDB在中国的普及以及技术社区工作。
14973 0
+关注
137
文章
1
问答
来源圈子
更多
蚂蚁OceanBase数据库团队,用于OceanBase技术原理、运维经验和案例分享、对外交流。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载