X-Engine 如何实现 Fast DDL

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 作者:旺德

5-6-3.gif
X-Engine是阿里巴巴自研的存储引擎,作为阿里云 RDS MySQL 的一个可选引擎,除了主打高性能和低成本,还增加了不少惠及用户的新功能。本文将详细介绍 MySQL(X-Engine) 如何近乎瞬时完成传统数据库需要数小时完成的DDL操作。

1.数据库DDL操作面临的问题

互联网业务发展迅速,应用模式频繁更改是常态。相应地,数据库访问模式和schema也随之变化。DDL(Data Definition Language)是SQL的一类,主要作用是创建和更改数据的schema信息,最常见的操作包括:加减列、更改列类型、加减索引等。熟悉MySQL的同学都知道,在8.0以前,虽然Online DDL不阻塞其它DML(Insert/Update/Delete)操作,但许多重要的DDL操作,如加列、减列等,仍旧需要等待数小时、甚至好几天时间(依据数据量的大小)才会生效。更改列类型等操作甚至仍需要锁表执行,阻塞DML操作。

DDL操作运行时间长,占用系统资源,需要额外的磁盘空间(建立临时表),影响系统吞吐,并且一旦DDL过程中实例crash,恢复时间也会很久。以加列DDL为例,MySQL经历如下过程:

1.以新schema建立空表。
2.拷贝数据到新表,并且将新加列的值赋为默认值,同时更新索引表。数据库接受到的DML操作被记录在临时文件。
3.加exclusive lock,阻塞写操作,将临时文件记录的DML操作apply到新表。如果DML很多,这一阶段将花费较多时间。
4.删除旧表,将新表命名为旧表的名字。

显然,这个过程加锁时间长,拷贝数据操作会占用系统资源和临时空间,并需要大量I/O。为了适应变化频繁的业务,不立即更改存储层数据、可以快速完成的DDL(我们称之为Fast DDL)成为了一个必要feature。MySQL 8.0 增加了instant add column功能,可以在短时间内只修改table元信息,完成加列操作。遗憾的是,它还不支持其它类型的DDL。得益于阿里自研的存储引擎X-Engine存储了多版本Table Schema,每一行记录在引擎层就完成了解析,并且可以依据更新版本的schema实现格式转换,X-Engine因此可支持多种类型的Fast DDL。

2.业界Fast ddl实现方案

MySQL 8.0

record记录了列个数, instant add column操作只修改系统表。

写操作:新格式的记录。

读操作:根据存储在系统表中default value补齐新加列。

支持类型:

• Change index optionRename table
• Set/drop default
• Modify column when the table is empty
• Add/drop virtual columnsAdd columns

MariaDB10.3

整体实现方案与MySQL8.0类似,record记录了列个数,在leftmost leaf page中记录所有列的default值.
支持类型:

• Add column
• Drop column
• Extend VARCHAR maximum (Only if the physical format allows; not VARCHAR(255) to VARCHAR(256))

Aurora

发生ddl后,更新系统表,新、旧版本的schema均要记录下来。然后广播该修改。之后接受DML请求,首先转换相关leaf page的所有记录,然后执行DML。

select请求会将旧版本的记录拼接成新版本记录。

支持类型

• only supports adding nullable columns, without default values

3.X-Engine多版本schema

顾名思义,Fast DDL指数据库能够在极短的时间内完成用户发出的DDL指令并返回。之所以这么快,是因为只修系统表里的元数据,不变更引擎层存储的数据。其实现的关键在于:元信息变更之后,内存、磁盘中的物理记录该如何解析。

Engine的架构采用了LSM-Tree的思想,将新写入的数据以追加方式写入内存memtable,memtable到一定大小后switch为immutable memtable,不再修改。然后逐渐以固定大小extent的形式,flush到持久化存储中。当extent到一定数量后,通过合并(Compaction)操作,将相同Key的多个版本合并。为了让每行记录可解析,最直观简单的方案便是将元信息附着在记录上面。为了能够不依赖系统表解析记录,X-Engine存储了较为详细的元数据,如果为每一行都附着一份,会占用大量的空间。为了大大减少存储成本,我们保证每个memtable和extent内部的数据schema一致,并将schema信息存储在memtable和extent之上。
image.png
schema信息包含了诸如列个数、列类型、列长度、默认值等关键信息。利用这些信息,X-Engine可以在返回结果之前,完成列解析,并只需返回查询目标列的对应结果。下面给出了一个具体的例子,同一张表存在不同schema版本的extent时,如何返回结果。
image.png

4.X-Engine fast ddl实现

当 MySQL 接收到一条fast ddl语句时,更新相关系统表及元数据,新版本的表结构随之生效,这时这条DDL语句就执行成功啦!到现在为止X-Engine存储的信息没有发生任何变化。

读请求

当系统接收到Select请求时,MySQL 会将请求本身,连同当前最新版本schema信息(称之为target schema)传递到X-Engine。X-Engine首先定位到记录的位置(某个memtable或extent),并取相应数据schema解析记录得到初步结果。接着,对比数据schema和target schema,对初步结果做适当填充、删减或修改得到最终结果返回。

X-Engine schema更新

Fast DDL命令执行成功,新版本的schema生效,X-Engine还对此无感知。当接收到第一条针对该表的DML(Insert/Update/ Delete)请后,如果发现X-Engine的活跃memtable的schema版本落后于最新版本,会触发switch memtable行为:冻结当前活跃memtable,产生新活跃memtable,将新schema赋予新活跃memtable。为了保证数据的正确性,该操作会等待所有正在进行的写事务完成后再执行。

写请求

每个写事务可能涉及到n(n>=1)个表。事务在提交时,需要在写入活跃memtable之前判断:事务写入数据的schema版本是否与活跃memtable的schema版本一致,如果不一致则应该报错退出,提醒用户重试。

Flush/Compaction

内存中memtable数量到一定个数时会触发Flush操作,被选中memtable的数据以extent的形式写入磁盘,schema也随之由memtable传递到extent。Compaction操作会合并多个extent,如果参与同一任务的extent schema版本不一致,X-Engine会以其中最新版本为准,生成新extent。

总结

Fast DDL可以解决很多应用的痛点,加列、扩展列的常用的操作不用再需要漫长的等待。技术上,X-Engine通过存储详细的多版本schema信息,不仅无需借助系统表解析记录,而且可以轻易地实现不同版本schema之间的数据转换,进而可以支持丰富的Fast DDL类型。

目录
相关文章
|
5月前
|
关系型数据库 分布式数据库 PolarDB
PolarDB操作报错合集之执行drop操作报The consensus follower is not allowed to to do current operation错误,select可以执行,是什么导致的
在使用阿里云的PolarDB(包括PolarDB-X)时,用户可能会遇到各种操作报错。下面汇总了一些常见的报错情况及其可能的原因和解决办法:1.安装PolarDB-X报错、2.PolarDB安装后无法连接、3.PolarDB-X 使用rpm安装启动卡顿、4.PolarDB执行UPDATE/INSERT报错、5.DDL操作提示“Lock conflict”、6.数据集成时联通PolarDB报错、7.编译DN报错(RockyLinux)、8.CheckStorage报错(源数据库实例被删除)、9.嵌套事务错误(TDDL-4604)。
126 1
|
6月前
|
存储 NoSQL 关系型数据库
实时计算 Flink版操作报错之抽取Oracle11g时,报错: "Retrieve schema history failed, the schema records for engine ... has been removed",怎么处理
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
自然语言处理 关系型数据库 MySQL
show engine inndob status执行流程简析
show engine inndob status执行流程简析
115 0
|
SQL AliSQL 数据库连接
PolarDB-X 源码解读系列:DML 之 INSERT IGNORE 流程
本文将进一步介绍 PolarDB-X 中 INSERT IGNORE 的执行流程,其根据插入的表是否有 GSI 也有所变化。
PolarDB-X 源码解读系列:DML 之 INSERT IGNORE 流程
|
SQL 存储 缓存
MySQL Online DDL增量DML记录和回放的源码实现
中分析并验证了MySQL进行在线创建索引时,不会因为执行时间过长或业务压力较大,在回放增量DML时加锁时间过久而对业务造成严重影响,本文从MySQL 8.0.19源码出发,分析MySQL是如何实现的。同时也确认是否在回放DML时会报duplicate key。 核心处理流程和对象 增量DML处理流程主要在http://row0log.cc中。 /** @file row/row0log.cc Modification log for online index creation and online table rebuild Created 2011-05-26 Marko Make
212 0
|
SQL Oracle 关系型数据库
xDB Replication Server - PostgreSQL, Oracle, SQL Server, PPAS 全量、增量(redo log based, or trigger based)同步(支持single-master, mult-master同步, 支持DDL)
xDB Replication Server - PostgreSQL, Oracle, SQL Server, PPAS 全量、增量(redo log based, or trigger based)同步(支持single-master, mult-master同步, 支持DDL)
886 0
|
缓存 算法 关系型数据库
PostgreSQL plan cache 源码浅析 - 如何确保不会计划倾斜
早上写了一篇文章,可以看到PostgreSQL为开发人员着想的,设计得非常人性化。《为什么用 PostgreSQL 绑定变量 没有 Oracle pin S 等待问题》https://yq.aliyun.com/articles/55698 同时也收到了一些朋友发来的问题,有朋友问我Postg
7717 0
|
SQL Oracle 关系型数据库
PostgreSQL 物化视图(Oracle同步到PG,PG同步到PG) - by pgsnapshot (plperlu trigger) (支持类似Oracle的mvlog fast complete force刷新)
标签 PostgreSQL , 物化视图 , 增量刷新 , mvlog , Oracle 同步到 PG , PG 同步到 PG 背景 PostgreSQL自身的物化视图没有MVLOG,也就是说,刷新的时候是VIEW定义产生的记录与MV已刷新的记录进行比对,进行增量更新的过程。
3338 0
|
SQL 关系型数据库 数据库
PostgreSQL sharding : citus 系列4 - DDL 操作规范 (新增DB,TABLE,SCHEMA,UDF,OP,用户等)
标签 PostgreSQL , citus , 新增对象 , 新增数据库 , 新增用户 背景 citus是PG的一个插件,插件主要针对普通SQL(非UTILITY)加HOOK进行了一些ROUTE处理,同时使用UDF对表进行新建分区的操作。
1855 0