突破底层基础架构瓶颈，揭秘TDSQL存储核心技术

TDSQL是腾讯面向企业级应用场景的分布式数据库产品，目前已在众多金融、政务、电商、社交等客户应用案例中奠定金融级高可用、强一致、高性能的产品特性和口碑，帮助20余家金融机构完成核心替换，有力推动了国产数据库的技术创新与发展。

日前，TDSQL新敏态引擎正式发布，高度适配金融敏态业务。该引擎可完美解决对于敏态业务发展过程中业务形态、业务量的不可预知性，实现PB级存储的Online DDL，可以大幅提升表结构变更过程中的数据库吞吐量，有效应对业务的变化；最关键的是，腾讯独有的数据形态自动感知特性，可以使数据能够根据业务负载情况自动迁移，打散热点，降低分布式事务比例，获得极致的扩展性和性能。

本期将由腾讯云数据库专家工程师朱翀深度解读TDSQL新敏态引擎存储核心技术。以下是分享实录：

TDSQL新敏态存储引擎

TDSQL在银行核心系统及常见业务上表现出优秀性能和良好稳定性，但在某些敏态业务中，其底层基础架构遭遇新的问题。

首先是兼容性的问题。TDSQL的架构包括计算层及分布式的存储层。分布式存储层中存在众多DB，利用中间层即计算层，再通过hash的方式将数据分片，分别存放在不同的DB。这种方式在建表时会遇到兼容性问题，需要指定shardkey才能将用户产生的数据存放到指定DB上。面对经常变化的敏态业务，如果每次建表都要指定shardkey，当业务变化时，指定的shardkey在未来业务中就不可用，需要重新去分布数据，整个流程将变得更繁琐。

其次是运维的问题。在TDSQL中，后端的存储节点是众多DB，如果容量不够则需要扩容。DBA需要在前端发起操作，过程较为简单，但途中会有部分事务中断。随着敏态业务的发展，需要不停扩容，扩容过程中的事务中断也会对敏态业务造成影响。

最后是模式变更的问题。随着业务的发展，敏态业务的表结构也在变化，需要经常加字段或加索引。在TDSQL中加索引等表结构变更必须锁表。如果想避免锁表，就需要借助周边生态工具。

基于上述问题，我们研发了TDSQL新敏态存储引擎架构。考虑到敏态业务变化较大，我们希望在TDSQL新敏态存储引擎架构中，用户可以像单机数据库一样去使用分布式数据，不需要关注存储变化，可以随时加字段、建索引，业务完全无感知。

目前该引擎完全兼容MySQL，具备全局一致性，扩缩容业务完全无感知，完全支持原生在线表结构变更。与此前架构最大的区别在于，该存储引擎为分布式KV系统，同时提供事务和自动扩缩容能力。在该引擎中，数据按范围分片，分成一个个Region，Region内部的数据有序排列。每个KV节点上有许多Region，每次扩容时只需要将指定Region搬迁走即可。

TDSQL新敏态存储引擎技术挑战

TDSQL新敏态存储引擎中数据是如何存储的以及SQL是如何执行的呢？以下图为例，t1表中有三个字段，分别是id、f1、f2，其中id是主键，f1是二级索引。在建t1表时，计算层会为其获取两个索引id，假设主键的索引id为0x01，二级索引的索引id为0x02。当我们为t1表插入一行数据时，insert into t1 value（1，3，3），计算层会把Key编码成0x0101（16进制表示法，下同，第一个字节0x01表示主键索引ID，第二个字节0x01表示主键值），value会被编码成0x010303。因为该表存在二级索引，所以插入一条主键Key还不够，二级索引也要进行编码保存；二级索引的编码中需要包含主键值的信息，故将其Key编码为0x020301（第一个字节0x02表示二级索引ID，第二个字节0x03表示二级索引值，第三个字节0x01表示主键值），因为Key中已经包含了所有需要的信息，所以二级索引的value是空值。

当我们为t1表再插入一行数据insert into t1 value（2，3，2）时，是同样的过程，这里不再赘述，这条数据会被编码成主键Key-value对即0x0102-0x020302，和二级索引Key-value对即0x020302-null。

假设后端有两个敏态引擎存储节点即TDStore，第一个TDStore上Region的范围为0x01-0x02，这样两个记录的主键就存储在TDStore1上。第二个TDStore上的Region的范围是0x02-0x03，这两个值的二级索引存储在TDStore2上。计算层收到客户端发过来的查询语句select * from t1 where id=2时，经过sql parse、bind等一系列工作之后，知道这条语句查询的是表t主键值为2的数据。表t的主键索引ID为0x