简介： 2021年5月20日，据国内事务处理性能委员会（TPC，Transaction Processing Performance Council）官网披露，蚂蚁团体自主研发的分布式关系型数据库OceanBase在数据分析型基准测试（TPC-H）中，以1526万QphH的性能总分发明了新的世界纪录。同时，OceanBase也成为惟一在事务处理和数据分析两个畛域测试中都取得过世界第一的中国自研数据库。
作者 | 陈萌萌
起源 | 阿里技术公众号
写在后面的话
2021年5月20日，据国内事务处理性能委员会（TPC，Transaction Processing Performance Council）官网披露，蚂蚁团体自主研发的分布式关系型数据库OceanBase在数据分析型基准测试（TPC-H）中，以1526万QphH的性能总分发明了新的世界纪录。
同时，OceanBase也成为惟一在事务处理和数据分析两个畛域测试中都取得过世界第一的中国自研数据库。
咱们特地邀请到OceanBase负责此次测试的核心成员陈萌萌撰文，讲述背地的技术思考。
以下为陈萌萌的自述。
收到期盼了好几天的审计员最终邮件，告知测试后果曾经挂到了官方网站。这意味着，测试小组的工作能够正式告一段落。接下来的60天，此次测试的报告将处于公示阶段，迎接全世界数据库专家的检视和挑战。
对我集体来说，本来期待的兴奋感没有如期而至。更多的是平静。平静地把官网上的测试报告又从头到尾读了一遍。按说，前前后后来来回回几十封邮件的技术沟通，报告外面的内容曾经烂熟。再读一次，既是出于技术人天生的审慎，更是不想因为一个低级谬误而让我的项目所有同学三个月的心血付诸东流。
对于为什么要冲击此次的榜单？简略来说，是因为明天的OceanBase曾经降级为一款反对 HTAP 混合负载的企业级分布式数据库，同时具备事务处理和数据分析两类场景的解决能力。咱们心愿市场对咱们有更多理解。权威中立机构的背书总好过“王婆卖瓜自卖自夸”。此外，从技术上说，这也是一件瓜熟蒂落的事件。只是，这个工夫点跟OceanBase对数据库的了解，以及将来想做的事件有密切关系。
一 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，我想也是适应了整个技术的大趋势。
二 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的价值。
三 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数据库，至多要可能比拟好的解决下面提到的三个方面的挑战。
四 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还很年老，还有很多机会，很多心愿。
原文链接
本文为阿里云原创内容，未经容许不得转载。