揭秘MySQL生态重要功能,X-Engine引擎核心能力——OnlineDDL-阿里云开发者社区

开发者社区> 阿里云数据库> 正文

揭秘MySQL生态重要功能,X-Engine引擎核心能力——OnlineDDL

简介: 作者:雁闲、无哈,阿里云数据库技术专家

概述

X-Engine是阿里自研的数据库存储引擎,以插件的方式接入到MySQL生态,支持行锁,事务,MVCC等OLTP场景的核心功能。

X-Engine的核心优势是低成本,高性价比,尤其适用于历史库场景,目前阿里巴巴内部的核心交易历史库(原来是Hbase),钉钉消息历史库(原来是MySQL(InnoDB)),淘宝商家的图片空间等业务均通过X-Engine解决了成本问题。

同时,X-Engine也赋能阿里云数据库服务,作为云上RDS-MySQL的存储引擎,对外售卖,让更多的用户享受到新技术带来的红利,有关X-Engine的详细介绍,请移步2019年10月的数据库内核月报。本文主要介绍X-Engine引擎的一个核心功能,OnlineDDL

OnlineDDL毫无疑问是MySQL生态的一个重要的功能,想当初MySQL 5.6以前,DBA执行DDL变更时,为了保证7*24小时服务,只能采用最老土的主备切换的方式来进行。数据库存储引擎区别于NoSQL引擎的一种重要指标就是是否支持SQL,是否有schema(数据字典)。有了schema,还需灵活地支持在线变更,这样才能从容应对业务快速变化的需求。MySQL生态中这么多存储引擎只有InnoDB完整地支持了OnlineDDL,X-Engine作为MySQL生态的新成员,虽然采用了完全不同于InnoDB的存储架构,但OnlineDDL给用户的体验是一样的 。

整体流程

X-Engine采用类LSM的分层架构,数据按照时序逻辑分成多层,每一层数据有序,新数据在较高的层次,最老的历史数据在最底层。对于X-Engine来说,每个主表和二级索引数据都是一棵分层的LSM-tree结构,内部称之为Subtable。每个Subtable分为4层,Memtable,L0,L1和L2,每一层都保持有序,数据按新旧顺序依次往更深的层次迁移,其中Memtable在内存中,其它几层按需可以在不同的存储介质上。OnlineDDL功能实现充分利用了X-Engine的数据组织特点,将新build数据分为两部分,基线数据和增量数据。基线数据是指变更开始时,通过拿snapshot能遍历得到的数据;增量数据是指,变更开始后,用户写入的新数据。拿Snapshot过程需要短时间禁写,因为我们强依赖这个一致性位点,确保基线+增量数据的完整性。

OnlineDDL总共包括了4个阶段,包括Prepare阶段,Inplace-build阶段,Commit阶段和Post-ddl阶段。

1、Prepare阶段,这个阶段主要是准备数据字典,构建底层存储数据的Subtable,为后续的增量写入做准备。

2、 Inplace-build阶段,这个阶段OnlineDDL的核心阶段,一方面通过Snapshot获取基线,另一方面还需要实时维护增量数据,利用X-Engine的数据组织的append-only特性,将基线和增量合并,即完成了OnlineDDL新数据构建的过程。这个过程的详细逻辑会在下一个小节详细介绍。

3.、Commit阶段,这个阶段是OnlineDDL引擎层变更生效阶段,如果整个OnlineDDL过程中没有出现异常或错误,那么Commit阶段会生效新的数据字典,生效新的数据。
4、 Post-ddl阶段,这个阶段是OnlineDDL真正生效阶段,这个阶段完成后,才会返回给用户DDL成功。这个阶段的引入,主要是因为MySQL通过Server层+引擎层这样的一个二层结构实现扩展,而每一层都有自己的数据字典,在Commit阶段只能保证引擎层的数据和数据字典是完整的,为了保证DDL变更的原子性(Server层和引擎层数据字典保持一致),引入Post-ddl阶段做清理和善后工作,有关DDL原子性的讨论会在下面的章节详细介绍。

核心逻辑

OnlineDDL的核心逻辑在于如何做到执行DDL变更时,不堵塞用户对该表的DML和SELECT操作。X-Engine实现OnlineDDL有两个关键点,第1,利用X-Engine的数据组织append-only特点,增量维护在Memtable,L0,L1中,而基线数据维护在L2中;第2,维护增量时,采用双写,同时维护old-table和new-table中的数据。与InnoDB引擎类似,根据DDL是否涉及到数据记录格式变更,将DDL变更分为Inplace-rebuild和Inplace-norebuild两种类型。对于X-Engine来说,两者本质是一样的,区别在于维护的索引个数。Inplace-rebuild类型的DDL需要同时维护new-table中所有索引;而Inplace-norebuild类型的DDL只需要维护new-table的新增的索引。
8afdfe79770545cfb9837a741c897bdf.jpg
整个Inplace-Build按照时间序有3个关键节点,t0时刻是获取快照的时间点,t1时刻是build基线完成的时间点,t2时刻是唯一约束检查完成的时间点。那么两个阶段的主要逻辑如下:t0-->t1主要工作是在build新表的基线,通过将old-table的数据结合new-table的数据字典生成新的记录,最终写入新表对应的L2层;在build新表基线的过程中,产生的增量写入到新表的(Mem,L0,L1)。DDL过程中,需要对后台的Compaction任务做一定的控制,确保不执行合并到L2的Compaction任务。t1-->t2是唯一性校验阶段,确保新增的主键或者唯一索引的唯一性,t2时刻将(Mem,L0,L1,L2)中的数据合并,最终得到new-table的全量数据。记录转换的过程如下:7bdf20ec4f474e42b359afe2d86d389d.jpg
其中,DDL事务表示DDL线程,它的任务是扫描基线,生成新表的基线数据;DML事务表示DDL过程中,并发的DML事务,它们的任务是,通过双写机制同时维护新表和老表的增量。

对比InnoDB实现逻辑

虽然X-Engine与InnoDB的OnlineDDL都是采用基线+增量的方式实现,但具体逻辑是不同的,主要是因为InnoDB采用的的是原地更新操作并且通过row-log机制来维护增量,而X-Engine是一个append-only的存储引擎,天然地支持数据的多版本存储,可以实时维护增量数据,在基线建立完成后只需要将基线与增量数据合并,即使基线中的数据在增量中被修改,但增量中数据的版本比基线数据版本更新,从而在合并时会覆盖基线中老版本的数据。下图是InnoDB引擎OnlineDDL过程。
3.jpg
可以看到InnoDB引擎的OnlineDDL也包括3个关键时间点,与X-Engine引擎的区别在于,t1-->t2 是InnoDB追row-log过程,而对应X-Engine是唯一约束检查的过程。当然对于X-Engine来说,t1-->t2不是必需的,因为DDL变更可能并不涉及唯一索引操作。

Instant-DDL

与MySQL8.0(InnoDB)类似,X-Engine同样也支持Instant-DDL。在所有支持的OnlineDDL中,若DDL操作只涉及修改表的属性信息,或只是做了加列操作,不需要修改记录格式,也不需要新增索引,那么这些OnlineDDL操作可以优化成Instant-DDL。这些DDL操作可以“极速”完成,用户基本无感知。由于Instant-DDL执行时,并没有真正涉及引擎数据的修改,为了后续查询结果和DDL操作的正确性,需要对于引擎的记录格式做一定的调整,加一些控制元信息。新增一个1字节来标示生成这个记录时,表是否执行过instant-ddl。同时,生成记录时,还需要记录有多少个列是已有的,以及有多少个null列等;在读取解析记录时,根据字典信息,就能知道有多少个列是需要根据instant列信息来补充,确保instant-DDL后,返回查询结果的正确性。

DDL原子性保证

从OnlineDDL的整体流程中我们了解到,OnlineDDL最后一个阶段是Post-ddl阶段。MySQL8.0以前,Server层的元数据都是通过文件来存储,比如frm文件,par文件以及trg文件等。一个DDL操作修改,涉及到文件修改,引擎数据修改以及引擎字典的修改,这些操作无法做成一个事务,必然导致整个DDL操作无法做到原子性。若DDL过程中出现异常,就可能会导致Server层和引擎层数据不一致,以及残余的垃圾没有清理等问题。MySQL8.0将Server层的所有字典信息统一存储在DD(DataDictionary)中,并且通过InnoDB引擎存储,那么DDL过程中,我们只要保证Server层数据字典的修改,以及引擎层数据字典的修改封装成一个事务即可。

对于InnoDB引擎而言,DD数据字典操作,InnoDB引擎数据字典操作都是通过InnoDB引擎存储,通过InnoDB事务特征来保证原子性。对于X-Engine引擎而言,DD数据字典操作,X-Engine引擎数据字典操作分别采用InnoDB引擎和X-Engine引擎,除了依赖于InnoDB和X-Engine自身是事务引擎特征,还需要借助于内部的2PC协议来保证整个事务的原子性。如果MySQL开启了binlog,那么就是binlog,X-Engine,InnoDB三者一起通过2PC协议保证事务的原子性。而Post-ddl阶段就是做善后和清理工作,如果最终整个事务提交,Post-ddl阶段负责真正清理old-table数据;如果最终整个事务回滚,那么Post-ddl阶段负责清理临时产生的new-table数据,确保DDL变更前后,数据库的状态是一致的。
4.jpg

使用体验

X-Engine作为MySQL的一个新引擎,在语法使用层面完全与MySQL(InnoDB)相同,通过algorithm_option指定Online类型,通过lock_option指定DDL过程中,是否允许其它并发的DML和SELECT操作。通常情况下,这两个选项都不用特别指定,采用默认值即可,MySQL内部会优先选择Instant类型和Inplace类型,对于不支持Online的DDL操作,选择Copy类型。在功能层面也与MySQL(InnoDB)相同,目前X-Engine暂时还不支持全文索引,虚拟列,外键等功能,因此与这些功能相关的DDL操作会不支持,其它DDL操作与MySQL(InnoDB)相同。常用的DDL操作分类如下:
5.jpg

后续工作

X-Engine作为一个新的数据库存储引擎,通过集团业务场景的打磨,已经体现了它的价值,我们希望通过云上RDS场景,让更多用户享受到新技术带来的红利。当然,目前X-Engine还有一些不足,尤其是相对于传统成熟的MySQL(InnoDB)和Oracle,所以X-Engine引擎在优化自身的稳定性和性能同时,会持续不断地丰富数据库功能,包括支持外键,全文索引,虚拟列等。除了公有云的RDS输出,基于X-Engine的一体化分布式数据库PolarDB-X也是一个重要方向,我们会以专有云形式输出,服务更多对分布式数据库有强需求的用户。

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云数据库
使用钉钉扫一扫加入圈子
+ 订阅

帮用户承担一切数据库风险,给您何止是安心!

官方博客
链接