OceanBase v4.2 特性解析：支持并发建表，提升OMS导入效率

背景

OceanBase 4.0版本新增了单日志流架构，使得OBServer单机突破了原有的分区数限制，支持更大数量的分区。

很多业务环境为了处理单机数据量过大的问题，通常采取分库分表的方法，这一方法会导致业务需要创建数十万乃至百万级别的表。然而，当这些业务迁移到OceanBase时，由于OceanBase集群内部DDL操作是串行执行的，使得通过OMS进行结构导入的过程变得异常耗时，经常需要数十小时才能完成，这无疑对迁移的效能造成了影响。

结构迁移的DDL以建表语句为主，所以要解决OMS结构导入的速度，关键就是要提升建表语句的吞吐。OceanBase v4.2.1对建表方案进行并发化改造，使无冲突的建表语句之间能并发执行，通过提高OMS结构导入DDL语句的吞吐，降低整体执行耗时。

实现原理

下面通过分别介绍串行DDL和并行DDL的实现原理，直观的从流程上感受DDL执行过程中耗时的地方，了解并行DDL功能改造的价值。

串行DDL

每个集群都有一个唯一的RootService服务，RootService服务所在的节点有一个DDL线程，集群内所有的DDL都会路由到RootService服务所在节点上串行执行。

如下图所示，两个不同的client的DDL请求路由到OBServer上，会内部路由到RootService服务所在的节点排队执行，客户端同步等待DDL的执行结果。视DDL请求的复杂度而定，执行单个DDL耗时一般在100ms以上；多个DDL请求按到达RootService服务所在节点的顺序，排队串行执行。

不论集群与租户的规格有多大，始终只有一个线程执行DDL。在高并发DDL场景下，受限于DDL集群内串行执行的限制，绝大多数DDL都在队列中等待执行，整体DDL的吞吐很低。但实际上集群有很多空闲资源有待利用。

并发DDL

OceanBase v4.1.0 版本初次提供了并发DDL执行的能力。如下图所示，通过扩展RootService服务所在节点的DDL线程数目，将单一DDL的实现拆分成不同阶段，同时将其中的部分阶段进行并行化改造。使得RootService服务所在的节点有一定的并发执行能力处理多个无冲突的DDL请求，有效提高整体DDL的吞吐。

上述改造使得RootService可以将所在节点中更多的空闲资源利用起来，进行DDL服务。RootService所在节点扩展出来的DDL线程数目跟集群的规格相关，因此当集群与租户的规格扩展时，DDL的执行能力也能随之扩展。

目前具备并发执行能力的DDL有：

truncate table：OceanBase 4.1.0版本版本开放相关能力。
create table：OceanBase 4.2.1版本版本开放相关能力。

使用说明

当集群以OceanBase 4.2.1之后的版本部署起来，或者升级到4.2.1之后的版本，并发建表的功能就会自动开启，无需用户额外进行配置。租户下可以执行以下语句查看当前租户的版本，当版本 >= 4.2.1，用户可以通过起多个并发执行建表语句启用并发建表的功能。

复制代码

MySQL [oceanbase]> show parameters like "compatible";
+------+----------+----------------+----------+------------+-----------+---------+---------------------------------------+--------------+--------+---------+-------------------+
| zone | svr_type | svr_ip         | svr_port | name       | data_type | value   | info                                  | section      | scope  | source  | edit_level        |
+------+----------+----------------+----------+------------+-----------+---------+---------------------------------------+--------------+--------+---------+-------------------+
| z2   | observer | 100.88.107.209 |     3025 | compatible | NULL      | 4.2.1.0 | compatible version for persisted data | ROOT_SERVICE | TENANT | DEFAULT | DYNAMIC_EFFECTIVE |
| z1   | observer | 100.88.107.223 |     3024 | compatible | NULL      | 4.2.1.0 | compatible version for persisted data | ROOT_SERVICE | TENANT | DEFAULT | DYNAMIC_EFFECTIVE |
| z3   | observer | 100.88.107.212 |     3026 | compatible | NULL      | 4.2.1.0 | compatible version for persisted data | ROOT_SERVICE | TENANT | DEFAULT | DYNAMIC_EFFECTIVE |
+------+----------+----------------+----------+------------+-----------+---------+---------------------------------------+--------------+--------+---------+-------------------+
3 rows in set (0.07 sec)

注意事项

并发DDL和串行DDL逻辑整体互斥，要想并发DDL整体达到最大吞吐，需要避免并发DDL执行过程中集群有其它的串行DDL执行。
由于DDL请求总是由RootService所在节点执行，为了减少DDL执行过程中的网络消耗，需要尽可能的保证RootService和租户leader在同一个节点上。
由于提高了建表的并发度，并发执行的DDL对系统会有额外的负载，需要消耗额外的资源。
系统租户需要有足够的线程响应DDL请求，想要达到DDL最大吞吐，系统租户需要额外的6C（CPU）。
用户租户需要有足够的线程响应DDL请求及写内部表的请求，想要达到DDL最大吞吐，用户租户需要额外的14C(CPU)。

同时，由于并发执行的建表语句吞吐量较大，短时间内会往内部表写入大量数据，对租户的内存、磁盘有额外的要求。租户磁盘较小内存难以转储落盘，而内存紧张的情况下会触发写入限速，影响并发DDL执行速度以及已有业务流量。

性能对比

OBSERVER建表性能测试

在以下部署方式下，使用不同方式创建不同数目的非分区表，有如下测试结果及结论。

环境部署

1：1：1部署，RS和租户leader部署在一起，压力起在备节点。
sys租户规格：16C32G
普通租户规格：8C80G

建表语句

DDL1：

create table t1 (c1 int primary key, c2 int, c3 varchar(20), c4 int, c5 timestamp, c6 int, c7 int, c8 int, c9 int, c10 varchar(20));

DDL2:

create table t1 (c1 int primary key, c2 int, c3 varchar(20), c4 int, c5 timestamp, c6 int, c7 int, c8 int, c9 int, c10 varchar(20), key i1(c4));

测试结果

|------------|--------|--------|----------|--------|---------------|----------|---------|---------------------------------|
| DDL类型 | DDL1 || DDL1 || DDL1 || DDL1 | DDL2 |
| 表数目 | 3,200 || 100,000 || 1,000,000 || 683680 | 683,678 (table)+683,678 (index) |
| 并发数 | 32 || 32 || 32 || 32 | 32 |
| 方式 | 串行 | 并发 | 串行 | 并发 | 串行 | 并发 | 并发 | 并发 |
| 总耗时（s） | 488.63 | 16.38 | 15928.64 | 549.61 | 159286.4(理论值) | 13775.08 | 6433.12 | 11441.5 |
| QPS（req/s） | 6.55 | 195.38 | 6.28 | 181.95 | 6.28(理论值) | 72.59 | 106.28 | 119.5 |

由于串行创建100W张表耗时过长，暂以10W表的性能为准，考虑到性能衰减，实际QPS会更低，仅用于与并发建表性能进行对比。

基于上述测试结果有以下结论：

随着建表数目的增加，受限于实时内存使用情况，串行建表和并发建表的性能都有所衰减。并发建表由于在较短时间内写入大量数据，衰减程度较为显著；串行建表总耗时较长，QPS较为稳定。
建表语句较为简单的情况下，并发建表性能较串行建表性能有10～30倍性能提升。
建表语句带索引，索引表相比用户表构建耗时更短，同等表(含索引)数目量级QPS会有所提升。
经测试，租户leader和RS不在同一个节点，DDL会涉及远程执行以及分布式执行，同等量级性能约衰减为原来的50%。

需要注意的是，该场景验证的相对简单的创建非分区表的性能，建表语句越复杂（是否分区、是否含索引/外键、是否带索引等），单个建表语句耗时越长，并发DDL的吞吐也会相应下降。但即便如此，并发建表的性能较串行建表也有10倍以上性能提升。

实际OMS导入场景实例

|-----|--------|-----------------|------|
| 集群规格： 8C32G 租户规格： 4C16GB mysql库表统计：Table：9101（非分区表）版本：4.2.1 ||||
| 模式 | 串行建表 | 串行建表+schema异步刷新 | 并行建表 |
| 总耗时 | 17 min | 13min | 5min |

该场景集群规格为8c，能够分配四个并行DDL工作线程进行并行建表任务。在同样尽力确保多机schema同步刷新的条件下，可以看到并行建表速度相比于串行建表速度提升了三倍多。而串行建表过程中将schema异步刷新的优化打开，并行建表也比串行建表速度提升了两倍多。