黄冈最专业的公司网站建设平台,wordpress 双域名,济南网站制作费用,hemi网站怎么做热图关于作者
谢振江#xff0c;OceanBase 高级技术专家。 2015年加入 OceanBase, 从事存储引擎相关工作#xff0c;目前在存储-索引与 DDL 组#xff0c;负责索引#xff0c;DDL 和 IO 资源调度相关工作。 回顾关系型数据库大规模应用以来的发展#xff0c;从单机到分布式无…关于作者
谢振江OceanBase 高级技术专家。 2015年加入 OceanBase, 从事存储引擎相关工作目前在存储-索引与 DDL 组负责索引DDL 和 IO 资源调度相关工作。 回顾关系型数据库大规模应用以来的发展从单机到分布式无疑是一个关键转变促成它的是层出不穷的新业务和爆发增长的数据量。
一方面更大的数据量意味着社会经济发展有了更多新可能另一方面它也对数据库提出了更高要求以避免存储节点增多带来的运维成本上升和可能出现的新故障。因此做好分布式数据库的透明性像使用单机数据库一样使用分布式数据库成为提升用户体验的关键之一。而 DDL 作为数据库运维中常见的变更操作它的执行自然应该对业务方和运维人员都透明。
“DDL 操作一定要等到夜深人静时”、“DDL操作执行时间很长有时甚至需要几周时间”……这些问题不仅令一线运维人员抓狂也是各个数据库厂商一直尝试突破的地方。OceanBase 认为上述问题的完美解决取决于实现高效且透明的 DDL即数据库应该尽可能快地执行 DDL并保证 DDL 执行期间不影响业务方和运维人员的操作。
在 OceanBase 4.0 中我们基于已有的原生 Online DDL 能力进行了创新首先为了提升 DDL 操作的可用性我们自研了一套专门用于旁路写入的数据同步方法此外我们对 DDL 的单机性能和分布式执行的可扩展性进行优化大幅提升用户 DDL 操作的响应速度最后4.0 进一步完善了原生 Online DDL 的框架能力支持了主键变更、分区规则修改、修改列类型和修改字符集等功能。
我们希望透过这些新变化帮助用户轻松应对各类复杂业务场景。本篇文章将讨论 OceanBase 如何实现高效且透明的 DDL介绍 OceanBase 4.0 DDL 的新能力及设计思路 更适合用户的 DDL 是什么样的 OceanBase 如何做好 DDL 来看看 4.0 DDL 有哪些新变化 4.0 DDL 新功能上手实测。 更适合用户的 DDL应该是什么样的 要回答这个问题我们需要先了解 DDL 的概念。在实际的数据库运维过程中除了 SELECTINSERTUPDATEDELETE 等这些常用的对数据本身进行操作处理的命令还有 CREATEALTER DROPTRUNCATE 等对表结构等数据库对象进行变更、与数据定义相关的命令这些命令被称为 DDL。举例来说常见的 DDL 操作有在表上增加新列、或给某列添加索引等。
在数据库发展早期执行 DDL 语句被视为最昂贵的数据库操作之一这是因为 DDL 操作通常会造成表不可读写阻塞各类进行中的任务。如果表的数据量很大会长时间中断数据库服务来执行 DDL这对于被要求时刻在线的关键业务是难以接受的。因此Online DDL 应运而生它的提出主要是为了能够在执行 DDL 时不阻塞正常的用户请求。目前市面上大部分数据库的 Online DDL 并未做到对用户完全透明 大部分单机数据库在 Online DDL 过程中存在短暂加锁的操作例如使用 MySQL 数据库在大事务场景中执行 DDL可能会阻塞用户的请求 受限于架构设计目前业界许多分布式数据库实现的 Online DDL在某些业务场景会对用户正常的请求造成影响 此外Online DDL 产生于单机数据库它通常只关注 DDL 是否对正常用户请求产生影响而对数据库节点发生异常如宕机时的应对并未提及。
而随着数据量爆发时代的到来DDL 的执行时长也会制约业务的迭代速度。在单机数据库中通常会采用并行排序来尽可能加速 DDL 的执行但它的执行速度受限于单机的性能瓶颈到了分布式数据库业界普遍使用模拟用户插入的方式来补全数据然而这种方式并不能充分利用单台服务器的性能也忽视了分布式可扩展能力提供的潜在性能。
可以这样说仅靠传统意义上的 Online DDL 已无法很好地满足实际业务需求。
我们认为更适合用户实际业务需求的 DDL 至少要具备以下两方面能力一方面DDL 的执行应避免对业务方的 DML、DQL 操作产生影响分布式环境也不会被运维人员感知即便发生宕机等异常DDL 操作也能成功另一方面DDL 操作应具备在单机和分布式上良好的并行处理能力帮助用户进行快速的业务创新。 OceanBase 如何做好 DDL OceanBase 希望为用户提供一款高效并且足够透明的数据库产品。
在透明性方面不同于单机数据库我们需要解决 DDL 操作过程中分布式数据库多节点状态不一致的问题。在应对这个问题时业界的大部分数据库采用了“DDL 优先”设计思路然而这种思路会在一些业务场景对用户请求产生影响。而 OceanBase 采用的是“业务请求优先”设计思路能避免对业务请求产生影响。此外我们也尽量屏蔽用户对分布式数据库的感知让用户像使用单机数据库一样在分布式数据库中执行 DDL。
在执行效率方面考虑到部分 DDL 操作会对数据进行补全而该步骤往往是 DDL 操作中最耗时的我们没有使用其他分布式数据库常用的模拟插入方式而是借鉴了单机数据库的设计思路并在分布式数据库中做到数据补全的性能可扩展实现足够高效的 DDL。
▋ 业务请求优先的分布式 Online DDL
在介绍 OceanBase 的 Online DDL 前不得不提的是分布式数据库领域中较为流行的 Google F1 在线异步 Schema 变更算法*出自论文《Online, Asynchronous Schema Change in F1》*CockroachDB 等众多分布式数据库的 Online DDL 功能均基于这一算法实现。该算法的实际过程较为复杂如果尝试用简单的话解释可以这样表述由于执行 DDL 过程中不能对表进行禁写大概率会出现不同节点有不同 schema 版本的情形而该算法会通过引入多个中间状态的 schema以保证数据的一致性。
进一步说Google F1 数据库由于没有全局成员列表所以在 DDL 执行过程中无法考虑机器和事务的状态会强制地周期性往前推进 Schema 版本而集群中需要保证同时使用的 Schema 版本不超过两个因此对于事务的执行时长有限制并且如果发生节点获取不到最新 Schema 版本的情况该节点会自杀退出影响其上所有的事务执行。总结而言F1 数据库会优先推进 DDL 的执行进程而不考虑对事务状态的影响因此我们将 F1 数据库的设计思路称为 DDL 优先的设计。
与 Google F1 不同的是OceanBase 的特点是有全局的成员列表在 DDL 变更过程中可以与 DDL 变更表格相关的成员进行协调当所有节点的事务状态都满足 DDL 变更一致性所需的条件时才推进接下来的 Schema 版本这样可以避免限制正常事务的执行在出现节点无法刷新到最新 Schema 版本时OceanBase 不会杀掉节点只会限制该节点正在执行 DDL 语句的表格相关的事务的执行同时不影响其他表格的执行因此我们将 OceanBase 的设计思路称为业务请求优先的设计。
我们以建索引为例测试 Google F1 和 OceanBase 在不同场景中执行 DDL 对业务请求的影响结果如下 OceanBase 3.xGoogle F1对正常事务的影响无影响限制执行时长无法获取最新 Schema 时进程存活影响正在执行DDL表格的相关的用户事务事务结束进程自杀节点宕机时执行时间变长无影响
表1 OceanBase 3.x 与 Google F1 建索引影响对比 而在 OceanBase 4.0 中Online DDL 除了具备业务请求优先对业务透明的特点之外还在数据库节点出现异常场景时增强了 DDL 操作的高可用特性即使在节点宕机时执行时间也不一定会变长具体内容会在后文中详细描述。
▋ 高效的数据补全方式
数据库中有部分 DDL 操作需要对数据进行补全比如建索引、加列等OceanBase 从 1.4 版本开始将这些需要补全数据的 DDL 操作划分为两种模式一种只需要在 Schema 上修改异步进行补数据的方式或称为 Instant DDL另一种则是需要实时补全数据的 DDL。
对于需要实时补全数据的 DDL业内大多数分布式数据库采用的是模拟用户插入的方式将数据补全这种方案的优点是实现简单可以复用 DML 的写入能力来完成数据写入并同步到备副本、备库等其缺点是性能差数据写入时会经过 SQL、事务、内存排序的结构在 LSM-Tree 存储架构中数据最终还要经过多次 compaction步骤繁琐。因此OceanBase 借鉴了单机数据库排序和旁路写入的思路进行数据补全。但与单机数据库不同的是OceanBase 需要进行分布式排序以及结合 LSM-Tree 存储架构展开优化以获得更好的性能。
一、分布式排序
在 OceanBase 3.x 版本中DDL 中的分布式排序复用了旧的 SQL 执行框架中的分布式排序能力其特点是具有分布式的性能可扩展性但在单机的执行效率上有提升空间。而在 4.0 基于新的 SQL 执行框架进行分布式排序后执行性能得到了大幅度提升。
二、结合 LSM-Tree 存储架构展开优化
不同于传统数据库的 BTree 的原地更新存储模型LSM-Tree 存储架构的特点是增量数据会更新到增量的数据源 Memtable 中不会对已写入磁盘的数据SSTable进行原地更新只有在 Compaction 时才会写入新的磁盘数据。这一特点为 OceanBase 加快 DDL 中的数据补全提供了极大的便利一方面对于加列这类操作可以自然地做到 Instant DDL只需要在 Compaction 的进行异步地数据补全另一方面对于建索引这类需要实时补全数据的 DDL 操作DDL 与 DML 会协调获得一个补全数据的版本号而该版本号之前的事务数据都已提交可以直接将补全的数据写入到 SSTable 中将 DML 产生的增量数据直接写入 Memtable 中因此建索引过程中的增量数据可以实时维护好无需类似于原地更新存储的追数据过程。
经过数年的发展迭代OceanBase 用户现在可以在线进行绝大部分 DDL 操作包括索引操作、列操作、生成列操作、外键操作、表操作分区操作。 功能分类支持的操作是否Online需要操作哪些数据添加索引是Schema元数据索引表数据删除索引是Schema元数据重命名索引是Schema元数据列操作添加列是Schema元数据主表数据Instant删除列是Schema元数据主表数据Instant重命名列是Schema元数据重排列是Schema元数据设置列默认值是Schema元数据删除列默认值是Schema元数据修改列类型是Schema元数据主表数据Instant设置列约束为NULL是Schema元数据设置列约束为NOT NULL是Schema元数据查询数据生成列操作添加VIRTUAL列是Schema元数据删除VIRTUAL列是Schema元数据添加STORED列是Schema元数据主表数据Instant删除STORED列是Schema元数据主表数据Instant外键操作添加外键是Schema元数据查询表数据删除外键是Schema元数据表操作修改行格式是Schema元数据主表数据Instant修改块大小是Schema元数据主表数据Instant重命名表是Schema元数据修改压缩算法是Schema元数据主表数据Instant优化表空间是Schema元数据主表数据Instant分区操作添加分区是Schema元数据删除分区是Schema元数据Truncate分区是Schema元数据索引表数据可选
表2 OceanBase 支持的 Online DDL 操作 来看看 4.0 DDL 有哪些新变化 ▋ 伴随业务成长的 DDL 新功能
在研发 4.0 之前我们了解到一些用户在新业务场景中需要经常对主键、分区等数据库对象的结构进行变更由于这类 DDL 操作需要将原表的数据进行重写我们称这一类 DDL 变更为需要数据重整的 DDL。
什么样的场景会需要数据重整的 DDL 呢
修改分区规则 某业务在一开始的规模较小在业务规模增长后数据量或者负载超过单机的规模而业务的查询更新语句中需要把某些列作为条件。此时需要按照这些列进行分区将数据量或者负载打散到多个节点上修改字符集 某业务刚开发时误将某一列的字符集 collation 设置大小写不敏感后来希望改造成大小写敏感的修改列类型 某业务表的列一开始定义为 int 列后来业务发生变化int 不足以表达业务的场景需要修改为 varchar 列修改主键 某业务的主键一开始使用业务自定义的 ID 列作为主键后来希望使用自增列来作为主键。
用户的业务成长不仅在于业务规模的增长也在于业务对数据库功能的使用更加深入。因此DDL 功能也必须长期支撑业务发展伴随业务成长。我们发现目前市面上的分布式数据库并未能对这类 DDL 操作提供良好的支持一是功能支持上不够完善例如部分数据库并不支持主键变更、分区规则变更等二是部分数据库在做数据重整时会采用模拟用户重新插入数据的方法将数据重新导出并插入一遍效率较低并且可能与用户事务产生冲突。
在 4.0 之前的版本OceanBase 对于数据重整的 DDL通常会采用手工数据迁移的方法完成变更。这种方法总体上有四个步骤在原表的基础上加入所做的 DDL 变更创建出一张新的空表将原表的数据导出将导出后的数据写入新表将原表重命名并且将新表重命名为老表。这一方法存在许多不足如操作步骤复杂任务失败时需要借助外部工具或者人工来回滚所做的操作迁移效率低遇到节点宕机会提高幂等性的处理难度比如无主键表场景等。
4.0 能为用户提供原生的数据重整 DDL 变更功能一条 DDL 命令即可完成所有操作包括修改分区规则、主键操作、修改列类型、修改字符集等用户无须关心 DDL 变更过程中出现的环境异常。 功能分类支持的操作主键操作添加主键删除主键修改主键列操作修改列类型包括变短、变长、跨类型变更修改自增列值添加自增列表操作修改字符集修改表中所有已有数据的字符集分区操作重分区 *非分区表转成一级、二级分区 **一级分区转成其他一级或者二级分区*二级分区转成一级分区或者其他二级分区
表3 4.0 DDL 新功能 为了支持好这些新功能我们也对原生的 Online DDL 进行了扩展 新增对多个依赖对象表格原子变更的能力 大幅提升了原生 Online DDL 的数据补全性能 旁路导入产生的数据也适用高可用的数据同步 对表上的数据以及表的依赖对象的数据都进行数据一致性校验保证 DDL 变更产生的数据正确性。
▋ 原子变更保证数据同步更新
原子变更能够保证用户在执行完 DDL 后如果 DDL 是成功的那么用户之后都会看到新变更后的表结构和数据如果 DDL 是失败的那么用户会看到变更之前的原表结构和数据。而进行需要重整数据的 DDL 变更会涉及到两方面的操作一方面需要对表上已有数据按照新的表格式进行修改另一方面需要对表上的依赖对象按照新的表格式进行修改如索引、约束、外键和触发器等。
另外由于分布式数据库中表上的数据可能分布在不同的节点上这也会带来两个问题 如何原子地将分布在不同节点的数据、多个依赖对象进行变更 每个节点感知到最新变更后的表结构的时间会出现不同如何保证在变更完成后用户只看到变更后的表结构。
为此我们设计了一套分布式环境下表结构的变更流程能保证原子地对数据、多个依赖对象进行变更并且用户在执行完 DDL 变更后能够使用最新的表结构来对表格进行查询、DML 等操作。
在实际业务场景中进行 DDL 变更也有可能会碰到数据库内核无法处理的异常。举例来说我们有一个列类型为 int 的表格该列上有一个唯一索引我们将这个列类型修改为 tinyint如果表中有多行的该列的列值超过了 tinyint 表示的范围那么这些行的所有列都会被截断成 tinyint 的上界导致多行在该列的列值有重复不满足唯一性约束。此时有可能数据已完成部分的重写DDL 在碰到这类异常后主动回滚时能够保证用户看到的是变更之前的原表的数据而不是看到处于变更到一半的状态。
▋ 并行能力提升数据补全速度
业界分布式数据库普遍采用模拟用户插入作为迁移数据的方式该方案存在两方面问题一是可能会和正常业务产生行锁冲突二是由于方案中对事务的并发控制、内存索引结构的线程安全控制、以及实际写入过程多次写入的情况其性能与传统单机数据库会存在明显差距。
为了在设计层面降低 DDL 变更对业务的影响同时让 DDL 具有更高的执行效率我们使用类似于 OceanBase 中索引创建采用的分布式排序、旁路写入的方式将原表的数据迁移到新表。分布式排序方式节省事务、内存有序结构维护、多次compaction等逻辑可以帮助用户节省 CPU 开销。而旁路写入能够避免数据写入到 Memtable 中以及出现多次 compaction 的情况节省内存和 IO 开销。
OceanBase 4.0 基于新的并行执行框架重新设计了 DDL 数据补全的分布式执行计划该计划分为两部分第一部分是采样和扫描算子第二部分是排序和扫描算子。 图1 OceanBase 4.0 DDL 数据补全分布式执行计划 该方案能充分利用分布式和单机并行能力
第一、两个并行子计划可能是运行在多台机器上的并且是新框架上同时调度起来的能够形成并行子计划 1 往并行子计划 2 吐行并处理的流水线
第二、为了防止分区间的数据倾斜我们将每个分区拆分成多份由不同的 sort 算子处理每个 sort 算子会处理多个分区的数据再结合采样划分算法让每个分区的数据划分相对均衡这样就能保证任务间的排序是均衡的。
另一方面在单机执行效率上我们通过一些技术提升了性能。如在补数据流程中尽量使用向量化来进行批处理、写本机磁盘数据和网络同步数据并行化、更高效的采样算法、新框架的静态数据引擎避免行的元数据反复拷贝等。上述优化对于所有需要补全数据的场景包括创建索引、数据重整的 DDL 性能提升都是有帮助的。
▋ 更严苛的可用性要求
分布式排序和旁路写入对数据补全的性能提升有很大的帮助但同时会带来一个问题旁路写入的数据如何同步到备副本和备库OceanBase 4.0 版本中支持将旁路写入到 SSTable 的数据通过 PAXOS 同步到备副本和备库在备副本和备库回放时只需要将 SSTable 中宏块的数据地址和元数据信息回放到内存状态机中这样做有如下好处 旁路写入的数据也具备高可用能力当少数派节点宕机时不影响 DDL 执行 旁路写入的数据是经过数据编码和通用压缩的数据量一般比原表数据量少很多数据同步性能好 备库和备副本的执行逻辑统一不再依赖特殊代码逻辑来处理数据同步代码更易于维护。
▋ 更全面的数据一致性校验
在做数据重整的 DDL 时需要将原表的数据迁移到新表我们希望在 DDL 变更后用户的数据是正确无误的。OceanBase 4.0 能够通过一致性校验保证 DDL 成功后迁移数据和原表数据的一致性即便 DDL 过程中发生了一些预期外异常导致数据不一致OceanBase 也会回滚掉该 DDL 操作。展开来讲OceanBase 4.0 会校验新表、新表上的索引、约束、外键等所有对象只有所有表中的数据依赖对象上的数据都是一致的DDL 操作才可能成功。 4.0 DDL 新功能上手实测 ▋ 新功能测试
一、主键操作
主键操作
添加主键
OceanBase(admintest)create table t1(c1 int);
Query OK, 0 rows affected (0.18 sec)--添加主键示例
OceanBase(admintest)alter table t1 add primary key(c1);
Query OK, 0 rows affected (1.28 sec)--添加主键验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) NOT NULL,PRIMARY KEY (c1)
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0 |
--------------------------------------------------------------
1 row in set (0.03 sec)删除主键
OceanBase(admintest)create table t1(c1 int primary key);
Query OK, 0 rows affected (0.19 sec)--删除主键示例
OceanBase(admintest)alter table t1 drop primary key;
Query OK, 0 rows affected (1.39 sec)--删除主键验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) NOT NULL
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0 |
--------------------------------------------------------------
1 row in set (0.03 sec)修改主键
OceanBase(admintest)create table t1(c1 int, c2 int primary key);
Query OK, 0 rows affected (0.18 sec)--修改主键示例
OceanBase(admintest)alter table t1 drop primary key, add primary key(c2);
Query OK, 0 rows affected (1.38 sec)--修改主键验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) DEFAULT NULL,c2 int(11) NOT NULL,PRIMARY KEY (c2)
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0 |
--------------------------------------------------------------
1 row in set (0.03 sec)修改分区规则
非分区表转成一级、二级分区
--非分区表转成一级分区示例
OceanBase(admintest)alter table t1 partition by hash(c1) partitions 4;
Query OK, 0 rows affected (1.51 sec)--非分区表转成一级分区验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) DEFAULT NULL,c2 datetime DEFAULT NULL
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0partition by hash(c1)
(partition p0,
partition p1,
partition p2,
partition p3) |
--------------------------------------------------------------
1 row in set (0.03 sec)OceanBase(admintest)create table t1(c1 int, c2 datetime);
Query OK, 0 rows affected (0.18 sec)--非分区表转换成二级分区示例
OceanBase(admintest)alter table t1 partition by range(c1) subpartition by key(c2) subpartitions 5 (partition p0 values less than(0), partition p1 values less than(100));
Query OK, 0 rows affected (1.96 sec)--非分区表转换成二级分区验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) DEFAULT NULL,c2 datetime DEFAULT NULL
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0partition by range(c1) subpartition by key(c2) subpartition template (
subpartition p0,
subpartition p1,
subpartition p2,
subpartition p3,
subpartition p4)
(partition p0 values less than (0),
partition p1 values less than (100)) |
--------------------------------------------------------------
1 row in set (0.04 sec)一级分区转成其他一级或者二级分区
OceanBase(admintest)create table t1(c1 int, c2 datetime, primary key(c1, c2))- partition by hash(c1) partitions 4;
Query OK, 0 rows affected (0.20 sec)--一级分区转换成其他一级分区示例
OceanBase(admintest)alter table t1 partition by key(c1) partitions 10;
Query OK, 0 rows affected (1.84 sec)--一级分区转换成其他一级分区验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) NOT NULL,c2 datetime NOT NULL,PRIMARY KEY (c1, c2)
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0partition by key(c1)
(partition p0,
partition p1,
partition p2,
partition p3,
partition p4,
partition p5,
partition p6,
partition p7,
partition p8,
partition p9) |
---------------------------------------------------------------
1 row in set (0.03 sec)OceanBase(admintest)create table t1(c1 int, c2 datetime, primary key(c1, c2))- partition by hash(c1) partitions 4;
Query OK, 0 rows affected (0.19 sec)--一级分区转换成二级分区示例
OceanBase(admintest)alter table t1 partition by range(c1) subpartition by key(c2) subpartitions 5 (partition p0 values less than(0), partition p1 values less than(100));
Query OK, 0 rows affected (1.88 sec)--一级分区转换成二级分区验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) NOT NULL,c2 datetime NOT NULL,PRIMARY KEY (c1, c2)
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0partition by range(c1) subpartition by key(c2) subpartition template (
subpartition p0,
subpartition p1,
subpartition p2,
subpartition p3,
subpartition p4)
(partition p0 values less than (0),
partition p1 values less than (100)) |
--------------------------------------------------------------
1 row in set (0.03 sec)二级分区转成一级分区或者其他二级分区
OceanBase(admintest)create table t1(c1 int, c2 datetime, primary key(c1, c2)) partition by range(c1) subpartition by key(c2) subpartitions 5 (partition p0 values less than(0), partition p1 values less than(100));
Query OK, 0 rows affected (0.23 sec)--二级分区转换成一级分区示例
OceanBase(admintest)alter table t1 partition by key(c1) partitions 10;
Query OK, 0 rows affected (1.98 sec)--二级分区转换成一级分区验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) NOT NULL,c2 datetime NOT NULL,PRIMARY KEY (c1, c2)
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0partition by key(c1)
(partition p0,
partition p1,
partition p2,
partition p3,
partition p4,
partition p5,
partition p6,
partition p7,
partition p8,
partition p9) |
---------------------------------------------------------------
1 row in set (0.03 sec)OceanBase(admintest)create table t1(c1 int, c2 datetime, primary key(c1, c2)) partition by range(c1) subpartition by key(c2) subpartitions 5 (partition p0 values less than(0), partition p1 values less than(100));
Query OK, 0 rows affected (0.24 sec)--二级分区转换成其他二级分区示例
OceanBase(admintest)alter table t1 partition by hash(c1) subpartition by key(c2) subpartition template(subpartition sp0, subpartition sp1, subpartition sp2) PARTITIONS 5;
Query OK, 0 rows affected (2.07 sec)--二级分区转换成其他二级分区验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) NOT NULL,c2 datetime NOT NULL,PRIMARY KEY (c1, c2)
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0partition by hash(c1) subpartition by key(c2) subpartition template (
subpartition sp0,
subpartition sp1,
subpartition sp2)
(partition p0,
partition p1,
partition p2,
partition p3,
partition p4) |
---------------------------------------------------------------
1 row in set (0.03 sec)修改列类型
修改某列的列类型包括变短、变长、跨类型变更、修改为自增列、修改字符集等等
OceanBase(admintest)create table t1(c1 varchar(32), c2 int, primary key(c1,c2));
Query OK, 0 rows affected (0.19 sec)--修改列类型变短示例
OceanBase(admintest)alter table t1 modify c1 varchar(16);
Query OK, 0 rows affected (1.47 sec)--修改列类型变短验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 varchar(16) NOT NULL,c2 int(11) NOT NULL,PRIMARY KEY (c1, c2)
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0 |
---------------------------------------------------------------
1 row in set (0.03 sec)OceanBase(admintest)create table t1(c1 varchar(32), c2 int, primary key(c1,c2));
Query OK, 0 rows affected (0.17 sec)--修改列类型变长示例
OceanBase(admintest)alter table t1 modify c1 varchar(48);
Query OK, 0 rows affected (0.17 sec)--修改列类型变长验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 varchar(48) NOT NULL,c2 int(11) NOT NULL,PRIMARY KEY (c1, c2)
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0 |
---------------------------------------------------------------
1 row in set (0.01 sec)OceanBase(admintest)create table t1(c1 int, c2 int, primary key(c1,c2));
Query OK, 0 rows affected (0.17 sec)--修改列类型跨类型变更示例
OceanBase(admintest)alter table t1 modify c1 varchar(48);
Query OK, 0 rows affected (1.38 sec)--修改列类型跨类型变更验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 varchar(48) NOT NULL,c2 int(11) NOT NULL,PRIMARY KEY (c1, c2)
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0 |
---------------------------------------------------------------
1 row in set (0.03 sec)OceanBase(admintest)create table t1(c1 int, c2 int, primary key(c1,c2));
Query OK, 0 rows affected (0.18 sec)--修改列类型将某列修改为自增列示例
OceanBase(admintest)alter table t1 modify c1 int auto_increment;
Query OK, 0 rows affected (0.58 sec)--修改列类型将某列修改为自增列验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) NOT NULL AUTO_INCREMENT,c2 int(11) NOT NULL,PRIMARY KEY (c1, c2)
) AUTO_INCREMENT 1 AUTO_INCREMENT_MODE ORDER DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0 |
---------------------------------------------------------------
1 row in set (0.01 sec)OceanBase(admintest)create table t1 (c1 int, c2 varchar(32), c3 varchar(32), primary key (c1), unique key idx_test_collation_c2(c2));
Query OK, 0 rows affected (0.24 sec)--修改列类型修改某列的字符集示例
OceanBase(admintest)alter table t1 modify column c2 varchar(32) charset gbk;
Query OK, 0 rows affected (2.12 sec)--修改列类型修改某列的字符集验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) NOT NULL,c2 varchar(32) CHARACTER SET gbk DEFAULT NULL,c3 varchar(32) DEFAULT NULL,PRIMARY KEY (c1),UNIQUE KEY idx_test_collation_c2 (c2) BLOCK_SIZE 16384 LOCAL
) DEFAULT CHARSET utf8mb4 ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0 |
---------------------------------------------------------------
1 row in set (0.05 sec)修改字符集
修改表中所有已有数据的字符集
OceanBase(admintest)create table t1 (c1 int, c2 varchar(32), c3 varchar(32), primary key (c1), unique key idx_test_collation_c2(c2));
Query OK, 0 rows affected (0.23 sec)--修改表中已有数据的字符集示例
OceanBase(admintest)alter table t1 CONVERT TO CHARACTER SET gbk COLLATE gbk_bin;
Query OK, 0 rows affected (2.00 sec)--修改表中已有数据的字符集验证
OceanBase(admintest)show create table t1;
--------------------------------------------------------------
| Table | Create Table |
--------------------------------------------------------------
| t1 | CREATE TABLE t1 (c1 int(11) NOT NULL,c2 varchar(32) COLLATE gbk_bin DEFAULT NULL,c3 varchar(32) COLLATE gbk_bin DEFAULT NULL,PRIMARY KEY (c1),UNIQUE KEY idx_test_collation_c2 (c2) BLOCK_SIZE 16384 LOCAL
) DEFAULT CHARSET gbk COLLATE gbk_bin ROW_FORMAT DYNAMIC COMPRESSION zstd_1.3.8 REPLICA_NUM 2 BLOCK_SIZE 16384 USE_BLOOM_FILTER FALSE TABLET_SIZE 134217728 PCTFREE 0 |
---------------------------------------------------------------
1 row in set (0.05 sec)▋ 性能测试
我们以创建索引为例进行测试往表格中导入一定行数的数据测试建索引的时间该时间主要消耗在索引数据补全通过该测试可以评测出各个数据库的数据补全性能。
实验配置
表结构: create table t1(c1 int, c2 varchar(755)) partition by hash(c1) partitions 10
数据量: 1000 万行
资源配置: 单机并行度 10排序内存 128M
测试场景
create index i1 on t1(c1) global;
create index i1 on t1(c2) global;
create index i1 on t1(c1,c2) global;
create index i1 on t1(c2,c1) global;
**对比指标**创建索引的耗时单位为 s
**对比产品**单机数据库 MySQL、某分布式数据库 A 以及 OceanBase 4.0。
性能测试结果 图2 性能测试对比 如上图所示其中数据库 A 是通过模拟插入的方式来进行补全的测试结果显示OceanBase 索引构建性能相对于数据库 A提升了 10-20 倍相对于 MySQL提升了 3-4 倍。因此使用排序和旁路写入方式来补全数据能大幅提升索引构建性能。OceanBase 4.0 经过单机性能优化数据补全的速度明显快于 MySQL。 写在最后 OceanBase 4.0 支持了常见的数据重整的 DDL 功能包括修改主键、修改列类型、修改分区规则、修改字符集等。我们希望通过原子变更、更全面的数据一致性校验和高可用的数据同步技术让用户只需要执行一条语句就能完成所需要的变更操作无须考虑分布式环境中出现的异常场景减少业务对分布式环境的感知使用上更加透明。同时我们提升了 DDL 的单机和分布式并行能力加快 DDL 中数据补全的速度使得 DDL 执行更加高效。
我们期待 4.0 对 DDL 功能的完善和优化可以帮助用户从容应对多变的业务挑战。
