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

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
云数据库 RDS SQL Server,独享型 2核4GB
简介: 作者:雁闲、无哈,阿里云数据库技术专家

概述

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的新增的索引。
11.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的全量数据。记录转换的过程如下:
12.jpg

其中,DDL事务表示DDL线程,它的任务是扫描基线,生成新表的基线数据;DML事务表示DDL过程中,并发的DML事务,它们的任务是,通过双写机制同时维护新表和老表的增量。

对比InnoDB实现逻辑

虽然X-Engine与InnoDB的OnlineDDL都是采用基线+增量的方式实现,但具体逻辑是不同的,主要是因为InnoDB采用的的是原地更新操作并且通过row-log机制来维护增量,而X-Engine是一个append-only的存储引擎,天然地支持数据的多版本存储,可以实时维护增量数据,在基线建立完成后只需要将基线与增量数据合并,即使基线中的数据在增量中被修改,但增量中数据的版本比基线数据版本更新,从而在合并时会覆盖基线中老版本的数据。下图是InnoDB引擎OnlineDDL过程。
13.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变更前后,数据库的状态是一致的。
14.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操作分类如下:
15.jpg

后续工作

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

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
6月前
|
监控 Cloud Native 关系型数据库
如何实现AnalyticDB MySQL版弹性能力
云原生数据仓库AnalyticDB MySQL版具备灵活弹性的特性,可应对大量客户并发访问时的流量峰值。
266 2
|
2月前
|
关系型数据库 MySQL 分布式数据库
PolarDB MySQL企业版与标准版功能对比:如何选择适合您的版本?
随着数字化时代的到来,企业对于数据处理的需求越来越高,而数据库作为数据处理的核心,其性能和成本成为了企业关注的焦点。阿里云全新推出的PolarDB MySQL企业版和标准版,以全新的架构和优化,为企业提供了高性能、低成本的数据库解决方案。但在功能上,这两个版本有很多差异,我们该如何选择呢?
20 2
|
6月前
|
Cloud Native 关系型数据库 MySQL
如何实现AnalyticDB MySQL多租户功能
本场景介绍如何通过云原生数据仓库AnalyticDB MySQL实现多租户资源隔离的功能。
164 0
|
2月前
|
JavaScript 关系型数据库 MySQL
基于JavaWeb和mysql实现网上书城前后端管理系统(源码+数据库+开题报告+论文+答辩技巧+项目功能文档说明+项目运行指导)
基于JavaWeb和mysql实现网上书城前后端管理系统(源码+数据库+开题报告+论文+答辩技巧+项目功能文档说明+项目运行指导)
|
2月前
|
关系型数据库 MySQL 分布式数据库
PolarDB MySQL版:强大功能,超高性能,满足企业级需求
PolarDB MySQL版:强大功能,超高性能,满足企业级需求 在当今信息化社会,企业对于数据处理的需求日益增长,如何选择一款高性能、高可靠性且成本合理的数据库成为了一大挑战。阿里巴巴的PolarDB MySQL版应运而生,它不仅兼容MySQL,还具备传统数据库所不具备的优势,为企业提供了更高效、更可靠的数据处理方案。
101 3
|
2月前
|
关系型数据库 MySQL Serverless
评测报告:阿里云 PolarDB MySQL 版 Serverless 能力
本次评测全面评估了阿里云 PolarDB MySQL 版的 Serverless 能力,包括资源弹升速度、资源伸缩广度、稳定性、颗粒度、自动启停以及全局数据强一致性。结果显示,PolarDB 在这些维度上均表现出色,能够快速响应负载变化、灵活调整资源配置、保证业务连续性和稳定性,同时精细控制成本。与同类型产品相比,PolarDB 在多方面具有优势。我们建议阿里云继续优化资源调度算法、拓展边缘场景支持,并加强与生态伙伴的合作,以进一步提升产品竞争力和用户满意度。
|
3月前
|
关系型数据库 MySQL Shell
百度搜索:蓝易云【Shell脚本实现Mysql持续kill功能】
将以上代码保存为一个名为 `kill_mysql.sh`的文件,并确保该文件具有执行权限(可以使用 `chmod +x kill_mysql.sh`命令赋予执行权限)。然后在终端中运行该脚本即可实现MySQL的持续kill功能。
43 0
|
3月前
|
SQL Java 关系型数据库
在IDEA中配置MySQL数据库连接以及在使用mybatis时设置sql语句的代码提示功能
在IDEA中配置MySQL数据库连接以及在使用mybatis时设置sql语句的代码提示功能
|
3月前
|
关系型数据库 MySQL 数据库连接
只用了nacos配置功能,多个nacos server连同一个mysql数据库会有啥问题吗?
只用了nacos配置功能,多个nacos server连同一个mysql数据库会有啥问题吗?
53 6
|
3月前
|
存储 安全 关系型数据库
mysql账号管理建库以及常用引擎
mysql账号管理建库以及常用引擎
31 0

相关产品

  • 云数据库 RDS MySQL 版
  • 推荐镜像

    更多