分布式OLTP数据库发展趋势（三）：在线模式变更（DDL）

数据库中的数据模式在系统运行的过程中并不总是一成不变的。一方面，随着业务的发展，通常需要增加新表或增加字段来满足新的业务需求；另一方面，随着数据量的不断增长，也可能需要添加新的索引来提升数据获取的效率。实际上，在线系统中可能会遇到更多场景的模式变更需求，如扩展字段长度、修改字段类型、添加索引条目等。对于重要的应用系统而言，无论是哪一种模式变更，我们都希望不影响系统当前的正常运行，对业务做到透明无感知。

回顾19世纪80年代，IBM早期研究人员在设计SQL时有两大目标：允许通过SQL来操纵和定义数据。这意味着，数据定义功能（简称“DDL”）从一开始就是SQL语言中最重要的组成部分。在之后数据库发展的几十年内，业界围绕DDL主要解决的核心问题是“模式演化”，即在保证数据一致性的前提下改变数据的定义。其中，在线模式变更（Online Schema Change）技术在众多的OLTP类型数据库中相继被实现并成为一项标准配置。

01

传统数据库采用加锁机制

对业务存在一定影响

传统数据库实现模式变更主要采用“锁表”方案。以MySQL早期版本为例，在进行模式变更时，首先创建一个与原表定义相同的临时表并对原表加写锁，然后将原表中的数据逐行复制到新表中，待数据复制完成后释放原表的写锁，最后将原表删除并将临时表重命名为原表名。 

图-MySQL早期版本模式变更流程

这种基于“锁表”方案的实现十分简单，因为不需要考虑事务并发带来的影响，但是这种方案同时也存在两个非常明显的问题。第一是额外的存储空间占用，试想如果需要修改的表数据量非常大而磁盘空间又比较小，在DDL完成之前会产生成倍的冗余数据，这可能导致磁盘空间不足的风险。第二就是整个修改过程中对原表添加写锁，因此这段时间原表都不能对外提供写操作，随着表的数据量越大，写阻塞的时间也就越长，这将阻碍业务的稳定运行。

为了降低对并发业务的影响程度，传统数据库针对在线模式变更的方案又进行了一系列的改进，大体思路是通过尽可能缩小加锁的范围来减少对并发写的阻塞时间。以MySQL 5.7版本为例，模式变更的过程整体上被划分为了三个阶段：准备阶段、执行阶段、提交阶段。在准备阶段会对表加一个比较短暂的排它锁，之后的增量数据被重定向到缓存对象中临时保存；执行阶段将原表的数据以及缓存对象中的增量数据重放到新表，此阶段表上的锁类型被降级为共享锁，因此允许并发的写操作；到了提交阶段，共享锁又被升级为排它锁，主要是为了把数据追平，保证最终一致。

图-MySQL 5.7版本模式变更流程

通过上述描述可以总结，以MySQL为代表的传统数据库为例，其在线模式变更主要有以下特点：

• 始终只有一个版本的模式

• 通过加锁方式保证一致性

• 可选择仅在关键步骤加锁，但仍然对业务有一定影响

02

分布式系统实现在线模式变更

数据一致性是难点

在线模式变更的前提是要保证任何时刻数据的一致性，如果不能保证这一点，那么即使性能再高也是无稽之谈。传统单机数据库在这一点上实现起来相对容易，仅需在关键时间点通过加锁的方式即可保证数据一致。而在分布式系统中，数据库由多个节点组成一个集群，为了保证查询执行性能，通常会在每个节点上缓存本节点已访问的数据库对象模式信息。由于节点之间存在一定的时钟偏差，不同节点上缓存的模式版本可能会不一致。以“创建索引”为例，在特定的时间点，可能会发生节点1上索引可见（V1版本）而节点2上索引不可见（V0版本）的现象，这会导致两种类型的数据不一致。

• 索引比表数据多。节点1往表中插入一条数据，由于此节点索引可见，因此表和索引各插入一条记录；节点2从表中删除这条数据，由于此节点索引不可见，因此只删除了表上的记录，索引上的记录被残留。导致索引数据比表多，数据不一致。

• 索引比表数据少。节点2往表中插入一条数据，由于此节点索引不可见，因此只有表上插入了记录，索引上对应记录为空。导致索引数据比表少，数据不一致。

图-分布式系统可能的数据异常场景

03

QianBase数据库实现异步无锁变更

对业务透明无感知

QianBase xTP数据库是易鲸捷专为金融领域打造的一款云原生分布式数据库，它主要面向关键业务类的OLTP场景，架构实现采用了完全去中心化的设计思路，集群所有节点完全对等部署，允许任意节点故障。在存储引擎层面，采用业内主流的一致性共识协议对数据进行多副本高可用保证。

分布式数据库在线模式变更之所以存在数据不一致，一个主要的原因是模式变更属于一次性变更。如果想要保证所有节点看到的版本都完全一致，最简单的实现方式是采用分布式锁来进行管理，但是这种实现方式的代价极高，工程实现上几乎不会使用。QianBase针对在线模式变更功能借鉴了 Google F1的思想，在模式变更期间引入多个中间版本，把变更过程由传统的一次性变更划分为多个相互兼容的步骤来完成。

图-QianBase引入多个中间版本完成在线模式变更

可以看出，QianBase在传统模式变更的基础上增加了DELETE_ONLY和WRITE_ONLY两个中间版本，将一次性变更拆解为ABSENT->DELETE_ONLY->WRITE_ONLY->PUBLIC 的演进过程。处于DELETE_ONLY版本的对象上只允许删除操作不允许读取操作，处于WRITE_ONLY版本的对象上允许DML操作但不允许读取操作。

同时，QianBase保证任意时刻集群内最多只有两个相邻的版本。比如在第一阶段时，部分节点已经转换为DELETE_ONLY版本，那么这些节点需要等待其他节点都转换为DELETE_ONLY版本后才能开始第二阶段。

现在我们分类讨论一下对于创建索引的过程这种机制如何保证数据一致性。

• 第一阶段(ABSENT->DELETE_ONLY)。ABSENT版本和DELETE_ONLY版本都不会向新增索引中插入数据，因此不会出现索引多出数据。ABSENT版本和DELETE_ONLY版本都无法读取到新增索引，因此也不会出现读取数据不一致。

• 第二阶段(DELETE_ONLY->WRITE_ONLY)。DELETE_ONLY版本和WRITE_ONLY版本都能够对新增索引删除数据，因此不会出现索引多出数据。DELETE_ONLY版本和WRITE_ONLY版本都无法读取到新增索引，因此也不会出现读取数据不一致。

• 第三阶段(WRITE_ONLY->PUBLIC)。WRITE_ONLY版本和PUBLIC版本都能够对新增索引删除数据，因此不会出现索引多出数据。WRITE_ONLY版本下会对存量和增量数据都进行处理，增量数据会同步维护到新增索引，存量数据会通过回填机制将索引中缺失的数据进行补齐。由于是在所有存量数据补齐完成后才会转换为PUBLIC版本，因此不会出现读取数据不一致。
  

以上仅简单描述QianBase数据库通过增加中间版本来保证在线模式变更过程的数据一致性。在实际的工程实现中还有很多其他细节问题需要解决，比如大数据量的回填耗时问题，QianBase在这些问题上都进行了对应的优化，从而真正实现了一套高效的、异步的在线模式变更机制。

党的二十大报告指出，教育、科技、人才是全面建设社会主义现代化国家的基础性、战略性支撑。必须坚持科技是第一生产力、人才是第一资源、创新是第一动力。加快建设网络强国和数字中国。贵州易鲸捷信息技术有限公司连日来深入学习党的二十大精神，将其贯彻至具体生产工作中，凝心聚力攻克科技技术难关，为我党实现第二个百年奋斗目标奋勇前进。

END

▼

往期精彩回顾

▼

易鲸捷简介

易鲸捷公司成立于2015年，专注于新一代融合型分布式数据库核心技术研发。公司核心团队源自天腾公司，曾创造过NonStopSQL等全球领先的数据库产品，核心技术完全自主可控。经过多年技术沉淀，易鲸捷已形成自主可控、国产可信、安全高效的三条完整分布式数据库产品线：QianBase xTP/QianBase TP/QianBase MPP，可面向不同行业应用提供完整的一站式解决方案，在金融、运营商、智能制造、5G等重点行业获得广泛应用。

网址：www.esgyn.cn

贵州易鲸捷信息技术有限公司 地址：贵阳市高新区长岭南路160号高科1号C座24楼
北京易鲸捷信息技术有限公司 地址：北京市朝阳区大屯街道北苑路万科时代中心奥林A座10层
上海易鲸捷信息技术有限公司 地址：上海市浦东新区金科路2889弄1号长泰广场A座6层03单元
北京：010-84983409	上海：021-50822117
邮箱：[e-mail]	网址：www.esgyn.cn