支付宝支撑2135亿成交额的数据库架构原理

OceanBase的SQL优化器和分布式并行执行
摘要：本文主要介绍蚂蚁金服自主研发的通用关系型数据库OceanBase，OceanBase采用了分布式架构，其经过技术创新在普通PC服务器集群上实现了更好的可靠性、可用性和可扩展行。本文中，蚂蚁金服OceanBase团队资深技术专家潘毅（花名：柏泽）为你们介绍了OceanBase，并分享了SQL优化器，分布式事务的执行逻辑等内容，为你们全面展示OceanBase底层事务引擎的技术创新。

1、OceanBase简介

OceanBase是蚂蚁金服自主研发的通用关系型数据库，其采用了分布式架构，目前支撑了蚂蚁金服所有核心链路系统。

为何要开发OceanBase
数据库做为基础软件，研发耗时较长且投入较大，那么，蚂蚁金服为何不能采用现成的方案，如商业数据库或者开源数据库呢？曾经，阿里巴巴拥有亚洲最大的Oracle集群，可是随着互联网业务的发展，尤为是近十年的发展很是迅速，阿里每一年的流量呈指数型上升，并且在某些特定日期流量会出现激增，这也是互联网行业与传统银行、电信等行业在数据库应用方面的不一样。传统行业能够制定将来几年的规划，如客户规模、业务量等，这些在必定程度上都是可预测的。可是互联网行业则不一样，互联网行业的流量变化很是快，一方面使用商用数据库很难进行迅速扩展来应对阿里巴巴飞速增加的规模；另外一方面，传统数据库的可靠性、高可用性等都须要依靠极其昂贵的硬件来实现，成本将会很是高昂。同时，阿里巴巴在高峰和平峰流量差异巨大，所以经过硬件实现特殊日期的高流量支持会形成严重的资源浪费。综上所述，现有的商业数据库并不能很好的支持阿里巴巴的整个互联网产业。而采用开源数据库一样也会致使一系列的问题，以MySQL为例，第一点，互联网产业的业务流量大，且并发高，须要每个查询都要在极短的时间内执行，所以对于通用数据库而言，必需要掌握核心的代码才能保证稳定的业务需求。第二点，金融行业须要具有强大的分析、查询能力的数据库，而MySQL在分析查询方面的能力比较薄弱，没法知足业务需求。出于以上缘由，蚂蚁金服须要开发一款数据库来知足自身的业务需求。

2、OceanBase架构

该部分将从集群拓扑、分区&分布式协议、存储引擎三个部分介绍OceanBase的架构设计。
1. 集群拓扑
多副本：通常部署为三个子集群，每一个子集群由多台机器组成，数据存储在不一样的集群中。
全对等节点：每一个节点的功能对等，各自管理不一样的数据分区。
不依赖共享存储：共享存储的价格较为昂贵，故采用本机存储的方式。

2．分区&分布式协议
数据分区：支持数据分区，每个数据以分区为单位做为管理组，各分区独立选主，写日志。
高可用&强一致：经过PAXOS协议保证数据（日志）同步到多数机器，发生故障时自动切主。

3. 存储引擎
OceanBase采用的存储引擎是经典的LSM-Tree架构，数据主要分为两个部分，分别是是存储于硬盘的基线数据（SSTable）以及存储于内存的增量数据（MenTable）。在该存储引擎中，全部数据的增删改操做都会在内存中进行，并造成增量数据，每隔一段时间将增量数据和基线数据进行合并，来避免对于SSD的随机写。由于对于数据库的操做为全内存操做，因此DML操做的效果很是好，但若是某一段时间的数据修改操做很是多，数据量过大，致使内存溢出，在这种状况下OceanBase提供了相应的解决方案，即转储操做，转储会将数据移动至硬盘上，但不会进行数据的合并操做，在后续合并时，会同时对增量数据，基线数据和转储数据一块儿进行合并。能够看出这个架构会面临一个很大的挑战，即在进行增删改的操做后，再进行查询操做，可能须要对基线数据和增量数据进行融合，所以在该架构下，读操做可能会受到必定的时间惩罚，这也是SQL优化器须要进行考虑的问题。事实上若是优化器不是基于自身架构和业务需求来进行开发的，可能不会得到良好的效果，这也是为何要自研数据库的另外一个理由。

3、SQL优化器

SQL优化的目标是最小化SQL的执行时间（计划生成+计划执行），该部分主要会从OLTP（Online Transaction Processing）和OLAP（Online Analytical Processing）两个方面进行SQL优化的介绍。对于数据量巨大的查询来讲，计划执行每每占据大部分的时间，可是对于不少数据量较小的查询，更多的要考虑计划生成的优化方案。

1.基于LSM-Tree结构的代价优化器
OceanBase优化器是基于经典的System R模式，主要进行两个阶段的优化。第一阶段是生成基于全部关系都是本地的最优计划，主要考虑的是CPU和IO的代价；第二阶段是并行执行优化，考虑的是CPU，IO，Network和Overhead的代价。同时，代价模型也须要考虑LSM-Tree结构的特色，好比进行MemTable和SSTable的数据融合，不一样表的代价可能不一样，所以代价须要采用动态采样计算；系统为分布式share nothing系统；索引回表操做会有额外的代价开销，使用的是逻辑的rowkey而不是物理的rowid，所以回表的时间消耗会增长等，这些都是优化器须要考虑的因素。

2.优化器的基本能力
优化器主要包括两种类型，分别是逻辑优化器和物理优化器，逻辑优化器主要作查询改写等操做的优化，好比基于规则和基于代价的优化，物理优化器主要对链接顺序，链接算法，访问路径进行优化，同时会考虑到Meta Data，好比统计信息，表分区信息。当有了统计信息和代价模型后，就能估算出模型的执行代价，而后选择出代价最好的模型进行相应的操做。而计划管理模块，对于OLTP的意义更加剧要，能够更好的对短查询进行优化。

3.优化器的统计信息
OceanBase优化器实现了很是完备的统计信息，包括表（avg rowlen, # of rows），列（column NDV, null value, histogram， min/max），分区／行级的统计信息。为了防止引入额外的开销，统计只会在数据进行大版本合并的时候进行。存储引擎对于某些谓词能够提供较精准的数据量Cardinality估计，好比经过谓词能够推算出扫描索引的开始和结束区间，在SStable中每一个block都有metadata统计行数，在MemTable中能够统计关于insert，delete，update操做的metadata。在OceanBase中，若是数据在合并过程当中进行了修改，会致使数据不够精准，此时将采用动态采样的方式来解决该问题。

4.访问路径
由于OLTP的SQL查询计划比较简单，通常来讲每每是单表，单索引的查询，因此访问路径对于OLTP很是重要。所以进行SQL查询时要进行相应的选择，例如主键扫描仍是索引扫描，采用单列索引仍是多列索引。选择的标准主要基于规则模型和代价模型，规则模型包括决定性规则（如主键全覆盖则采用主键扫描进行查询）和剪枝规则（运用skyline剪枝规则，多个维度比较，选择更好的索引）。以后再经过代价模型的比较选出最优模型进行查询。模型主要考虑的因素包括：扫描范围，是否回表，过滤条件，Interesting order等。

5.计划缓存
计划缓存是指在一个计划生成以后，后续若是出现同一个查询或者类似的查询，可使用现有的计划而无需从新生成计划，计划缓存经过高效的词法解析器匹配输入的查询语句，使用参数化查询优化进行匹配。下面为一个计划查询的例子。

能够看到，在计划缓存中对于查询语句会进行参数的模糊匹配，但对于特定含义的参数会加入限定条件，好比order by 3中的参数3表明是第三列，该参数的修改可能会致使计划缓存的不适用，所以存储计划缓存时加入了限定条件@3 = 3。

6.自适应共享计划
对于一个查询语句只要参数类似就必定能进行计划缓存的匹配吗？答案是否认的，举一个例子，在一个查询语句中对于salesman由于数据量较大，会采用全表扫描的方式进行查询，而对于president，由于数据量很是少，可能经过索引的方式进行查询的代价要比全表扫描的代价更好，所以对于这种状况，一样须要加入相应的限定条件。但从新生成的计划可能和原有计划相同，发生这种状况后，便会对于原有的限定条件进行修改，方便以后的查询语句进行计划匹配，以此来达到自适应计划共享。

7. Hint/Outline
在OceanBase中若是对于自动化生成的计划不满意，也能够经过建立Outline的方式来绑定自定义的计划，也就是经过Hint来制定计划的生成，Hint的类型十分丰富，包括：access path, join order, join method, parallel distribution等，下面是Outline绑定的两个例子。

8.SQL计划管理及演进
不少用户特别是企业级用户对于稳定性的要求很是高，所以OceanBase在进行系统升级，统计信息更新，硬件更新后会自动进行一个流量的演进，即同时运行新计划和老计划，当肯定新计划相较于老计划无性能回退时，才会逐渐将老计划替换成新计划。

9.分区及分区裁剪
OceanBase支持多种分区类型，包括Range，Hash，Key，List。对于二级分区支持Range/Range, Range/Hash, Range/List, Hash/Hash, Hash/Range等。对于静态或动态分区裁剪支持inlist， 函数表达式，join filter等多种方式。

10.查询改写
查询改写主要包括基于规则的改写以及基于代价的改写，基于规则的改写主要包括视图合并，子查询展开，过滤条件下推， 链接条件下推，等价条件推导，外链接消除等。基于代价的改写主要包括OR-expansion，Window function等，查询改写对于OLAP的优化效果很是好。下图为基于代价模型的改写框架。

4、SQL执行引擎

优化器和执行引擎是相辅相成的，优化器所能优化的计划取决于执行引擎的执行计划。
1.并行执行
并行执行的概念就是分治，分治包括垂直分治（好比拆分计划为子计划单元）和水平分治（好比GI(Granule Iterator)获取扫描任务），并行执行主要用于OLAP场景中，解决查询RT时间的问题，这在不少在线分析的场景下是十分必要的。RT时间对于RDBMS查询是一个重要指标，传统的Map-Reduce的执行性能并不能知足OLAP的性能需求，所以如何找到高效的执行计划及数据流水线很是关键。在OceanBase中采用两级调度，自适应的子计划调度框架，各节点独立的任务切分等方案来进行并行执行。对于数据重分布，OceanBase支持大多数常见的数据分布，包括Hash， Broadcast/Replicate,，Round Robin，Merge Sort等。

2.两级调度
在OceanBase中经过下面所述的方式造成两级调度。即将查询涉及到的各个机器上分别建立一个执行节点（SQC），来让主控节点（QC）控制SQC，其中QC为机器级的控制，SQC为线程级的控制。QC进行全局调度，依据总并行度分配各节点各子计划并行度， SQC进行本机调度，其中各节点独立决定水平并行粒度及执行。

3.计划动态调度
计划动态调度是指根据用户指定或系统资源自适应决定在容许的资源使用范围内，减小中间结果缓存，构建2组或以上计划子树的执行流水线(垂直并行)，这种方式能够有效的避免物化，减小物化算子对并行执行所形成的不良影响。该功能正在开发测试中。

4.并行执行计划
OceanBase中拥有全部主要算子的并行执行方法，包括nested-loop join, merge join, hash join,aggregation, distinct, group by,window function, count, limit等，同时支持丰富的重分布方法和多种候选计划，例如partition-wise join, partial partitionwise join,broadcast, hash, sort(for distributedorder by)等。
事实上，并行查询的优化技术在MPP架构下产生了新的问题，好比分区链接要求各表的分区从逻辑上和物理上都是同样的，这也是一个须要考虑和优化的方向。

5.编译执行
传统执行方式如类型检查，多态(虚函数)对于内存操做很低效。OceanBase考虑采用LLVM 动态生成执行码，SQL表达式能够支持动态生成执行码，存储过程采用直接编译执行的方式，来进行性能提高。

整理：杨德宇