PolarDB MySQL运维能力优化

更新时间:2024-10-16 02:06:28

本文将介绍传统数据库在处理大表时所采用的解决方案并分析PolarDB体系下针对这些大表的优化处理方法。

DDL运维能力优化

并行DDL

传统的DDL操作依赖于单核处理和传统硬盘设计,这使得针对大表的DDL操作耗时较长,延迟过高。以创建二级索引为例,过高的延迟DDL操作会阻塞后续依赖新索引的DML查询操作。多核处理器的发展为并行数据定义语言(DDL)的使用提供了更强大的硬件支持。同时,固态硬盘(Solid State Disk,简称SSD)的普及使得随机访问延迟与顺序访问延迟的差距大大缩小。因此,采用并行DDL技术加速大表的索引创建显得尤为重要。

PolarDB并行DDL功能能够充分利用数据库的硬件资源,大幅度降低DDL操作的执行时间,避免阻塞后续相关的DML操作,从而缩短DDL操作的窗口期。

并行DDL上线以来,已经成功帮助众多客户解决了在大表中添加索引时遇到的难题。根据真实用户反馈,启用并行DDL功能后,对于一张5 TB、60亿行的大表,仅需1小时即可完成二级索引的添加。

下图展示了在使用不同并行线程数时,使用并行DDL在不同数据量的表中为数据类型为INT的字段b创建二级索引所带来的DDL执行效率提升比例。可以看到,当开启32个线程时,最高可实现2000%的性能提升。

image

秒级DDL(添加字段)

在使用传统方法进行加列操作时,往往需要重新构建整个表的数据,这会消耗大量系统资源。PolarDB秒级加字段(Instant add column)功能,在进行加列操作时,只需更改表的定义信息,无需修改已有的数据。

image

秒级修改字符集

UTF-8编码是一种广泛使用的字符编码方式。在社区版MySQL中,当使用UTF-8时,系统默认采用utf8mb3编码集。此编码集最多使用3个字节存储字符。当需要存储emoji等信息时,通常需要将utf8mb3字符集转换为utf8mb4。然而,字符集的转换往往涉及到表的重建,这个过程可能耗时较长,并对业务造成一定影响。PolarDB支持在秒级内将字符集从utf8mb3修改为utf8mb4。借助这一功能,您可以便捷地完成字符集的转换,让您的数据库更好地支持多种字符和符号。

ALTER TABLE tablename MODIFY COLUMN test_column varchar(60) CHARACTER SET utf8mb4, ALGORITHM = INPLACE;
说明

使用上述语句时,若返回ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.这意味着当前操作无法以inplace算法执行。建议您仔细核对相关的使用限制。

在不指定ALGORITHM或选择ALGORITHM=DEFAULT的情况下,PolarDB会自动找到执行效率最高的算法来完成修改操作。将列的字符集从utf8mb3转为utf8mb4时,可以无视表的大小,在秒级完成操作。以下是相关的示例语句:

ALTER TABLE tablename MODIFY COLUMN test_column varchar(60) CHARACTER SET utf8mb4, ALGORITHM = DEFAULT;
ALTER TABLE tablename MODIFY COLUMN test_column varchar(60) CHARACTER SET utf8mb4;

快速TruncateDrop大表

在社区版MySQL 5.7中,执行TRUNCATE TABLEDROP TABLE操作时,需要扫描整个缓存池(Buffer Pool),将与表空间对应的所有数据页从LRU listFLUSH list中删除。当Buffer Pool较大时,相关操作可能会耗时较长。为此,PolarDBDDL过程中Buffer Pool的管理机制进行了优化,从而显著提升了Buffer Pool的扫描效率,进而加快了TRUNCATE TABLEDROP TABLE的执行速度。

使用方法

您可以通过loose_innodb_flush_pages_using_space_id参数开启Faster TRUNCATEDROP TABLE功能。

使用效果

在不同规格的集群中,记录了开启和关闭Faster TRUNCATEDROP TABLE功能后,对t1表和t2表进行TRUNCATE TABLE操作所需的执行时间(以秒为单位)。其中,t1表插入8196行数据,用于模拟小表TRUNCATE情况,t2表插入2097152行,用于模拟大表TRUNCATE情况。实验结果如下所示:

集群规格

Buffer Pool(GB)

t1

t2

ON

OFF

提升率

ON

OFF

提升率

集群规格

Buffer Pool(GB)

t1

t2

ON

OFF

提升率

ON

OFF

提升率

64512 GB

374

0.01

5.2

99.81%

0.11

9.48

98.84%

32256 GB

192

0.02

2.45

99.18%

0.1

2.65

96.23%

16128 GB

96

0.01

1.73

99.42%

0.12

1.86

93.55%

864 GB

42

0.01

0.73

98.63%

0.12

0.79

84.81%

432 GB

24

0.02

0.45

95.56%

0.13

0.53

75.47%

416 GB

12

0.03

0.23

86.96%

0.12

0.35

65.71%

从上表可以看出,开启Faster TRUNCATEDROP TABLE功能后,能显著提升TRUNCATE TABLE操作的执行效率。

非阻塞DDL

在执行DDL操作时,如果目标表上存在未提交的长事务或大查询,DDL操作将持续等待获取MDL-X锁。在PolarDB中,MDL-X锁具有最高优先级,因此在等待期间,DDL操作将阻塞对目标表的新事务。这种情况可能导致业务连接的堆积和阻塞,从而严重影响业务运行,甚至可能导致整个系统崩溃。

为了解决这一问题,PolarDB针对在线 DDL提供了非阻塞DDL功能。开启该功能后,DDL语句的锁策略将与工具(如gh-ostDMS的无锁变更)保持一致,确保无锁或无损地执行业务。同时,由于PolarDBDDL流程是内核原生实现,其性能显著优于外部工具,DDL操作将具备类似于外围工具的无损特性,并保持内核的高性能,从而显著减少对业务的影响。

使用方法

您可以通过loose_polar_nonblock_ddl_mode参数开启Nonblock DDL功能。开启后,在业务高峰期执行DDL时,即使无法获取锁,也不会对业务产生影响。

使用效果

  • 关闭Nonblock DDL,TPS持续跌至0。默认超时时间为31536000,严重影响业务。

    image

  • 开启Nonblock DDL,TPS周期性下降,但未跌至0。对业务影响较小,能保证业务系统的稳定。

    image

  • 使用gh-ost进行表结构无锁变更,TPS周期性跌0。对业务影响很大,这是cut-over阶段短暂锁表造成的。

    image

  • 性能对比:使用SysBench工具下oltp_read_write模拟业务负载,通过下图可以看出开启Nonblock DDL并使用传统的加列方式(INSTANT、INPLACE、COPY)比使用gh-ost工具耗时更少。

    image

总结

image

从当前云产品的发展趋势来看,几乎所有主要云产品提供商都推出了兼容性最强的解决方案,并将其作为云平台的核心产品。

对于云服务提供商而言,兼容性是最重要的需求之一。对于许多中小型客户而言,100%的兼容性是一个重要的参考指标。客户将产品迁移至云端时,往往会考虑现有开发人员的技术栈和存量代码。因此,任何不兼容的情况出现都会导致开发人员需要付出额外的学习成本,同时也会增加对现有业务进行改造的成本,从而给客户带来额外的支出。当然,随着业务的壮大,可能会出现大表影响业务发展的情况,性能不再满足需求且没有数据清理方案,那时再考虑相关问题也为时未晚。

  • 本页导读 (1)
  • DDL运维能力优化
  • 并行DDL
  • 秒级DDL(添加字段)
  • 秒级修改字符集
  • 快速Truncate或Drop大表
  • 非阻塞DDL
  • 总结
AI助理

点击开启售前

在线咨询服务

你好,我是AI助理

可以解答问题、推荐解决方案等