欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

AppBoxFuture(四). 随需而变-Online Schema Change

程序员文章站 2022-05-20 19:38:17
  需求变更是信息化过程中的家常便饭,而在变更过程中如何尽可能小的影响在线业务是比较头疼的事情。举个车联网监控的例子:原终端设备上传车辆的经纬度数据,新的终端设备支持同时上传速度数据,而旧的车辆状态表数据量超过亿级,此时如果Alter table add column将会造成数据 ......

  需求变更是信息化过程中的家常便饭,而在变更过程中如何尽可能小的影响在线业务是比较头疼的事情。举个车联网监控的例子:原终端设备上传车辆的经纬度数据,新的终端设备支持同时上传速度数据,而旧的车辆状态表数据量超过亿级,此时如果alter table add column将会造成数据表上锁,导致上传或查询车辆状态数据等待。appboxfuture的存储引擎在设计之初也是采用锁表的方案,后来考虑到上述应用场景决定支持online schema change,但带来了另一个难题是如何保证分布式环境下的一致性。

  在权衡了利弊后,作者决定采用如下草图所示的变更方案,主要是考虑工程实现上的便利性。实现的关键点是实体模型内有schemaversion标记,在添加删除列、索引、entityref引用外键时,schemaversion+1, 同时所有表分区的状态机内也有schemaversion标记当前的版本,如果变更过程中有旧版本的insert\update\delete命令,则抛出schemachanged错误,由上层逻辑加载新的模型后重试。该方案的优点是实现简单,且变更过程对在线业务的影响较小,缺点是变更任务不支持回滚,如遇到网络或磁盘错误则任务会稍候重试(幂等),添加惟一索引例外,遇到主键冲突任务不会重试,改为通知上层删除该索引。
AppBoxFuture(四). 随需而变-Online Schema Change

  作者在虚拟机(i74c8g)内做了个单分区80万行记录添加列变更性能测试,如下动图所示:
AppBoxFuture(四). 随需而变-Online Schema Change
测试结果如下约0.8秒就处理完一个分区80万行记录:

#01/17/2019 11:17:07 [debug] [storeservice.updatemodelasync]: entity[vehiclestate] schema changed, 2 -> 3
metaaltertable::tryrunastask: 开始提议分区变更任务至68719476742
metaaltertable::tryrunastask: 分区提议成功68719476742
kvalterpartion::tryrunastask: 分区批次处理完成
metaaltertable::tryrunastask: all partition done, elapsed time:0.847791s
metaaltertabledone::apply: 移除变更任务, 剩余任务:0
kvalterpartiondone::apply: 移除分区变更任务, 剩余任务:0

  如果您有问题或bug报告,请留言或在github提交issue。