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


从时间上看,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 年就像在“打地基”的阶段,你说我将来要做某某内饰风格,至少当时没有想到那么具体的事情,但是我知道分布式一定是这个房子的“地基”,我们要盖的是一个摩天大楼,而不是一个独门小院 。这个是打破传统数据库设计限制的前提,想通了这个事儿,后面的技术落地就比较自然了 。
Alibaba 蚂蚁自研数据库OceanBase登顶TPC-H榜单,核心成员撰文讲述背后思考
文章图片

为什么分布式数据库是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核,几十台机器同时为一个查询服务 。万事万物,只要涉及到“协同“,就有成本 。把协同的成本降低到最低,考验的是系统整体的设计 。

推荐阅读