火山引擎云数据库 veDB 在字节内部的业务实践( 二 ) 大数据和云原生时代

什么是读延迟？主备架构中的主机写完数据之后，备机不能立刻读取数据，这其中的延迟被称为读延迟。这其中面临的问题是什么呢？首先是传统的主备架构，比如MySQL基于Binlog同步，只读节点延时受业务负载影响比较大，虽然它在v5.7版本引入并行回放机制改善了读延迟，但是并没有完全克服问题；另外计算存储分离之后，团队并不是基于Binglog构造数据，而是基于Redo日志构造数据，那么RO节点如何同步数据呢？团队提供了以下技术解决方案。解决方案页面（Page）级别并行回放机制：首先只读节点启动后， veDB会基于最新快照，持续从共享存储去拉取物理日志并行解析回放，值得注意的是， veDB可以根据不同的规格选择不同的并行机制；
Redo日志拉取（Pull）模式：这种模式下的计算节点读写， RW节点和RO节点之间并没有直接的网络交互（如上图所示），只读节点从存储池拉取Redo日志；
Redo日志推送（Push）模式：Push模式是指在RW节点完成日志持久化之后，直接把Redo日志推到只读节点。

文章图片
为什么会有Pull和Push两种模式呢？两种模式效果并不相同，在Pull模式下， veDB能够支持30+RO节点，但此时读延时较高，大约在100毫秒左右。在Push模式下， veDB能够支持15个左右的RO节点，此时读延时较低，大约在10毫秒左右。数据导入能力优化
对于如何更快从MySQL迁移数据，传统方式是MySQL本身支持Dump、Restore ，或者第三方工具支持MyloaderMydumper ，但由于存储计算分离，这种逻辑转换方式的性能表现并不佳。
解决方案首先，考虑到InnoDB存储层物理页格式是一致的， veDB引入Fastloader工具直接把页面批量写入到存储层（Pagestore），其中，有些信息需要更新，比如InnoDB表的SpaceID、索引的ID、LSN等。同时， veDB目前支持MySQL5.6/5.7/8.0去导入数据。
文章图片
优化效果如何呢？总体而言，对于24G（1亿条）数据，用时从1637s降到32s ，性能提升了51倍；对于69G（3亿条）数据，用时从21585s降到95s ，性能提升了227倍。
大表DDL处理优化
原生MySQLV8.0版本支持Instant的DDL特性，虽然比较快，但是它适合的场景有限。另外， MySQL备机回放DDL的Binlog时，它会引入一个较大的主备时延，只有DDL执行完成，它才能执行其它进程，这会造成较大的问题。目前各大互联网公司包主要运用两个第三方工具Ghost和Pityonlineschemachange ，来解决主备延时的问题，不过执行效率较低。尤其对veDB来说，存储计算分离之后，表变得更大，延时问题更加凸显。解决方案
veDB引入了FastDDL来解决以上问题，具体而言：
主键索引（源表）页面预取：DDL分为两个阶段，第一个阶段是对原表主键索引进行全表扫描，然后在这一阶段进行精准的页面预取；
并行构建（按索引，多机房）：第二个阶段就是并行构建，比如按照索引并行构建，团队要重新构建表，其中包含10个索引，那么会有10个并发；同时，如果机房之间通过Binlog去同步，团队可以多机房一起执行；
存储层Write-Through：veDB架构的特点是LogisDatabase 。为了优化DDL ，团队直接写入Pagestore ， Bypass了Logstore ，起到一定的加速作用。

文章图片
关于优化效果，主要有以下三点：
普适：基本上MySQL能够支持任何OnlineDDL的操作；快：它作为一个内部实现工具，是gh-ost速度的十分之一；静：团队不引入Binlog主备延时，比如机房分别执行DDL ，等待它们执行差不多，最后relay就能完成。复杂查询下推处理优化