数据库内核月报

数据库内核月报 － 2021 / 12

PolarDB · 引擎特性 · Nonblock add column

Author: zhp259558

Oracle add column的特征

1. 同一事务会看到不同的版本的DD

SQL_1> select * from test;

 A
----------
 1

           SQL_2> alter table test add b number;

           Table altered.

SQL_1> select * from test;

 A	       B
---------- ----------
 1

Oracle 不保证事务访问到的DD（data difination）的一致性，而在MySQL中，由于MDL的保护，普通事务是不允许跨DDL的，因此任意普通事务只能看到单一版本的DD。

2. DDL会被写事务堵塞，但后续新的写事务不会被DDL阻塞

SQL_1> insert into test values(1,2);

1 row created.

                                    SQL_2> alter table test add c number not null;
																																	 
                
                   SQL_3> insert into test values(1,2);

                   1 row created.
                                                                            
                   SQL_3> commit;
																																		
                   Commit complete.

Oracle中，DDL会被写事务阻塞，但此时后续新的写事务不会被该DDL阻塞。而在MySQL中，由于MDL-X锁具有较高的优先级，因此一旦DDL被未提交的事务阻塞，后续该表上的所有新事务都将被阻塞以防止MDL-X锁饥饿。

3. 被阻塞的DDL不会被后续新事务阻塞

SQL_1> insert into test values(1,2);

1 row created.

				SQL_2> alter table test add c number not null;
																																		 
		SQL_3> insert into test values(1,2);

		1 row created.


SQL_1> rollback;

Rollback complete.
                                 
		Table altered.                                                 
				SQL_3> commit;
																																		
				Commit complete.

SQL_1> select * from test;

	 A	    B	       C
---------- ---------- ----------
	 1	    2

SQL_1> desc test;
 Name					   Null?    Type
 ----------------------------------------- -------- ----------------------------
 A						    NUMBER
 B						    NUMBER
 C					   NOT NULL NUMBER

当DDL被事务1阻塞后，新进的事务3正常执行，当事务1回滚后DDL将执行完成，而不会被未提交的事务3阻塞。

但值得注意的是，在该场景下似乎出现了DD和数据不一致的情形，列C有NOT NULL NUMBER约束，但是查询出来的数据列C没有值（该行由事务3写入）。但对该问题我们未做深入探究。

从以上几个特征可以看出，Oracle的add column的约束比MySQL要弱，它不保证DD的事务特性。与DML事务的并发能力比MySQL要强很多，也不会出现MySQL常见的锁表问题。

PolarDB Nonblock add column的能力

1. Nonblock add column不会被未提交的事务阻塞

我们在一个会话中开启一个新的事务，在表t1中插入数据，但不提交。

image-20211223150656311

开启一个新的会话，我们首先查询数据，在RC的隔离级别下，未提交事务写入的数据不可见。然后做add column操作，该操作可以立即完成，而不会被未提交的事务阻塞。

image-20211223150051835

2. 保持DD的事务一致性，跨DDL的事务只能访问到一个版本的DD

回到第一个会话，查看表结构并继续插入数据，此时由于该事务开始时间在add column之前，所以新增的列对其不可见。提交该事务后重新查询，我们将看到最新的表结构。

image-20211223150504858

切换到第二个会话，当第一个会话的事务提交之后，查询将看到最新的已提交数据。

image-20211223150811350

PolarDB Nonblock DDL的基本原理

1. DD多版本技术

说到多版本技术，最为人熟知的就是数据库的MVCC。Innodb MVCC的基本原理是允许每一行数据保持多个历史版本，这些版本通过undo链组织，每个事务在读取数据时都持有一个read view，通过read view判断该事务应该读取哪个版本的数据。通过MVCC，Innodb解决了数据读写相互阻塞的问题。但是，当我们把眼光投向DDL的时候，我们就会发现DD的读写仍然是相互阻塞的：DDL本质上是DD的写操作，而DML/DQL则是DD的读操作。因此为了实现DDL的Nonblock，我们需要在DD中引入MVCC技术，为每一个DD的元素赋予版本信息，允许同时存在DD元素的多个版本，同时为每一个事务绑定一个DD的read view。在访问DD时通过DD的read view判断DD元素的可见性并读取相应的版本。

2. DD元素的多版本存储

在MySQL8.0，所有表的DD信息都存储于Innodb中，以表的形式组织。整个DD的存储体系如下所示

image-20211227112701734

Server层和引擎层的DD信息都来于storage，这个storage就是InnoDB。在DEBUG模式下编译代码，并调用如下SQL语句，我们能看到所有用于存储DD的Innodb表。

set session debug='+d,skip_dd_table_access_check';
select name from mysql.tables where hidden='System' and type='BASE TABLE';

mysql> select name from mysql.tables where hidden='System' and type='BASE TABLE';
+------------------------------+
| name                         |
+------------------------------+
| dd_properties                |
| innodb_dynamic_metadata      |
| innodb_ddl_log               |
| catalogs                     |
| character_sets               |
| collations                   |
| column_statistics            |
| column_type_elements         |
| columns                      |
| events                       |
| foreign_key_column_usage     |
| foreign_keys                 |
| index_column_usage           |
| index_partitions             |
| index_stats                  |
| indexes                      |
| parameter_type_elements      |
| parameters                   |
| resource_groups              |
| routines                     |
| schemata                     |
| st_spatial_reference_systems |
| table_partition_values       |
| table_partitions             |
| table_stats                  |
| tables                       |
| tablespace_files             |
| tablespaces                  |
| triggers                     |
| view_routine_usage           |
| view_table_usage             |
+------------------------------+
31 rows in set (0.02 sec)

从这些表名，我们可以看到，MySQL将DD的信息分门别类的存储在不同的表中，例如columns表存储列的定义信息，indexes表存储索引的定义信息，这些DD的不同子项就是我们所说的DD元素，DD的多版本就是DD中这些元素的多版本。实际上在内部我们曾讨论过多版本信息的粒度问题。

  1. 粗粒度的实现整个表的多版本存储，DD中逻辑上存在table_v1，table_v2等同一个表的不同版本信息。
  2. 细粒度的实现特定元素的多版本存储，对表而言仅有一个版本，但是列/索引等DD元素存储多版本信息。以列信息为例，在该方案下表中的列具有如下图所示的逻辑结构。

image-20211227132640934

虽然细粒度的方案实现起来细节更多，但考虑的工程上的可迭代性，我们仍然选择了方案2。依据该方案的思路，我们率先实现了列信息的多版本：每个表有一个单调递增的唯一版本号，每个列在创建/修改时会从该版本号中分配一个。

3. 事务的DD ReadView

Innodb事务中存储了m_low_limit_id，m_up_limit_id，以及活跃事务列表m_ids等核心信息，用来选择数据的确切版本。因为我们不支持DDL本身的并行，也就是说任意时刻某个表上活跃的DD事务一个，所以DD的read view只需要记录目标表上单调递增的版本号就可以了，因此一个事务的DD ReadView有如下逻辑结构。为了保持MySQL DD语意的一致性，对DML/DQL事务来说，DD的读取总是RR的，当事务第一次访问到某个表时，DD ReadView中就记录了相应的版本，后续直到事务提交，该事务都只能看到该版本的DD信息（对Oracle来说，DD的读取可以认为是RC的，DDL事务提交后，非DDL事务可以立即看到最新的DD）。

image-20211227135401706

4. 一次DDL和DML的并发过程

我们在下文抽象出DDL和DML的事务并发过程，该过程的一个实际例子在前文已有展示。

1. DML transaction begin;
 1.1 open table t1;
 1.2 build DD ReadView of table t1 (t1:v1)
 1.3 use DD ReadView (t1:v1) to operate Data
        2. DDL transaction begin;
         2.1 operate data
         2.2 operate DD
         2.3 update table version to v2
         2.4 commit
 1.4 operate data with DD ReadView(t1:v1)
 1.5 commit and release DD ReadView

3. DML transaction begin;
 3.1 open table t1;
 3.2 build DD ReadView of table t1 (t1:v2)
 ...

从上述流程中，我们可以看到，非DDL事务在open table时将构建DD ReadView并绑定，随后DDL的执行将不被未提交的事务阻塞，DDL提交后，事务利用ReadView仍然能保证随后看到同一个版本的DD。

Nonblock DDL的后续演进

1. Scope的扩大

PolarDB Nonblock add column已经在内部测试阶段，后续我们将支持更多DD元素的多版本，支持更多的DDL类型，目前在开发计划之内的DDL类型包括modify column type，add index。此外Converting table character set仍在调研阶段，modify column type和Converting a character set是目前为数不多的几个仅支持copy算法的常用DDL，解决这类DDL的并发问题是有非常大的意义的。

2. 限制的放宽

目前Nonblock DDL仅在普通表上得到了支持，在分区表或者含有Trigger/FTS/Foreign key等的表上还无法使用，这些类型的表在MySQL内部实现中关联了多个内部数据结构，具有更复杂的DD操作流程，后续我们将对这些特殊的的表进行适配和支持。