腾讯云TDSQL-C 全球数据库技术揭秘

0 阅读1分钟

本文内容节选自6月13日,由msup和高可用架构联合主办GIAC全球互联网架构大会,腾讯云数据库技术专家冉仟元分享的《TDSQL-C 全球数据库技术揭秘》案例实录。

分享者冉仟元,有10余年的数据库存储开发经历,曾供职于华为、阿里巴巴、字节跳动,2023 年加入腾讯云数据库云原生研发团队,目前负责 TDSQL-C(for MySQL) 技术方向。主要关注高性能计算网络、分布式存储方向。

目录

• TDSQL-C 技术架构演进

• TDSQL-C 全球数据库核心技术解析

演讲全文

TDSQL-C 是腾讯云自研的新一代云原生关系型数据库。融合了传统数据库、云计算与新硬件技术的优势,为用户提供具备高弹性、高性能、海量存储、安全可靠的数据库服务。TDSQL-C MySQL 版100%兼容 MySQL 5.7、8.0。实现超百万级 QPS 的高吞吐,最高 PB 级智能存储,保障数据安全可靠。

TDSQL-C 采用存储和计算分离的架构,所有计算节点共享一份数据,提供秒级的配置升降级、故障恢复,单节点可支持百万级 QPS,自动维护数据和备份,最高以GB/秒的速度并行回档。

TDSQL-C 技术架构演进

TDSQL-C 技术演进路线

传统MySQL架构存在的痛点:存储容量受限于本地磁盘,无法支撑超大规模实例;主从延迟高达秒级,DDL操作与大事务会进一步加剧延迟问题;只读备机构建速度缓慢(分钟或小时级),垂直与水平扩缩容能力差;读副本需冗余存储,且存在严重的写放大等问题。TDSQL-C的初始目标就是朝着解决这些问题。

TDSQL-C 最开始是基于 “Log is Database” 这种架构,这种架构最小化网络IO,存储层能解析 redo log。内核和存储深度组合优化,避免了 RW 节点页面刷脏,checkpoint 等行为。同时存储层内嵌了数据库内核部分功能,性能和扩展性更强。另外,随着一些外部客户的需求以及技术迭代的演进,最近一年我们也在探索和实现对等架构,这种架构支持多个写节点,写性能进一步提升;算子下推结合内核并行查询能力,提升HTAP处理能力。

TDSQL-C 产品演进路线

• 2017年 - 2019年 :2017 年立项,基于存算分离架构,解决数据库独立、弹性伸缩问题,满足云原生数据库业务诉求。2019 年正式商业化,成为国内首批 Log is Database 架构的云原生数据库产品。

• 2021年:发布serverless版本,是国内首个使用 serverless 架构的云原生数据库,为超 10 万企业用户及 50 万微信小程序开发者提供服务,助力传统企业数字化转型。

• 2023 年:并行查询和列存索引功能相继发布,TDSQL-C 的 HTAP 能力增强,复杂查询效率提升 4 - 17 倍。

• 2025 年 :即将发布 TDSQL-C 全球数据库版本,实现分布在全球不同地域的多个 TDSQL-C 集群间数据同步,助力全球业务轻松出海部署。

TDSQL-C 全球数据库核心技术解析

全球数据库架构

全球数据库是一个可跨城市、跨国甚至跨洲际部署的数据库网络集群,不同区域间有全量数据集,通过高效物理复制同步数据。支持一个主 Region,最多 7 个从 Region,每个 Region 可挂载 15 个 RO,分担读压力,实现区域内就近读,多地部署提供全球容灾能力。

主Region中,写请求生成的Redo日志持久化至高速存储引擎LOGSTORE,并备份至对象存储COS;从Region通过standby节点同步Redo日志,该Region内的其他RO节点则链接该standby 节点,获取日志进行内存更新,从而提供一致的数据读服务。若从Region接收到写请求,会通过Proxy或内核直连透明转发至主Region执行,确保全局数据一致性。

底层存储引擎 DBSTORE3.0

为支持全球数据库功能,底层存储引擎 DBSTORE 从 2.0 升级到 3.0。

(一)DBSTORE2.0 架构

2.0 存储层的设计和实现,着重体现了 ”Log Is Database“ 的理念,其含义是日志中包含了数据的信息,可以从日志中恢复出用户的数据,这种架构带来的好处是:

• 计算层完全无状态,为秒级节点升配、秒级增加从库提供基础;

• 计算层无页面恢复开销,缩短启动时间;

• 避免页面刷脏,从根本上减少了计算节点 B+ Tree 的写放大问题,减少计算层和存储层的 I/O 量。

而 DBSTORE 作为可计算存储,主要承担着持久化日志、回放日志、读写数据页面,提供多版本等功能。随着业务需求的不断变化,以及更极致性能的诉求,DBSTORE 2.0 在发展过程中也面临着一些问题:Redo日志按小表粒度打散存储到 DBSTORE 中,按当前设计,如果需要获取连续的日志备份及定阅能力,需更重新设计存储格式和索引,复杂且性能损耗;

(二)DBSTORE3.0 架构

引入 LOGSTORE 组件,主要用于接收和存储REDO日志,同时升级了 PAGESTORE 的主要功能。

• 性能提升 :LOGSTORE 主要用于持久化日志,DBCLIENT无需解析,流式的日志发送提升了前台写日志速度,PAGESTORE主要负责后台异步批量分发和部分计算功能。通过逻辑解耦的方式使各个组件发挥自己的架构优势,突破性能上限。相比有主架构,DBCLIENT 到 LOGSTORE 链路采用无主架构,减少网络延时,消除长尾毛刺影响。

日志功能增强

为满足 standby 全量数据集需求,主库需提供连续的日志流。除内存日志外,还需要提供订阅冷日志的能力。两个模块:log ring buffer(内存区域存储最近日志)和 CDP Agent(从存储订阅一段范围的日志)。当 standby 请求日志时,如果日志范围在 ring buffer 内,则从内存读取,否则下发给CDP,从 LOGSTORE 或 COS 获取。对数据库实例而言,日志获取透明。standby在从主库读取到日志后,会拷贝一份用于异步发送到存储进行数据更新,另一份则用于更新其内存中的数据页

发送效率优化

由于全球数据库可能跨洲际部署,网络延迟大。例如广州到美国圣克拉拉,单线程发送日志上限仅 15MB/ 秒,无法满足生产环境数据复制低延迟要求。解决方案:主库通过多线程并发提高发送效率。主库为每个 standby dump请求生成一个协调线程和多个 worker 线程,协调线程从log buffer或者cdp中获取一段区域的日志,然后计算好并行执行的分片,每个worker 线程发送各自分片到 standby,standby 接收线程拷贝日志到本地,进行持久化和内存应用。从测试来看,线程数与传输效率基本成正比,16个线程可以满足大部分场景,24个线程可以满足高吞吐下的全球复制。

可用区切换

可用区切换,这里主要分为两种,一种是计划内切换:比如需要为全球数据库进行版本更新,或者用户负载发生变化主动进行切换。另一种是计划外切换,这通常是遇到不可抗力,例如整个可用区完全不可用,为了保证服务的连续,需要将另外一个可用区提升为主Region。

计划内切换:一个主region和两个从region, 在具体实现中,我们首先将Primay降级为standby并写入一条降级日志,之后不可在接受任何写操作。其他region的standby接受到降级日志,会将自己设置为可升级状态,表示数据已经完全同步。

然后我们选择一个可升级的standby,将其在线修改为primary, 然后通过change master命令将其他standby指向新的primary, 这样计划内的可用区切换就完成了

计划外切换 :当可用区故障,需要进行非计划内切换时,管控通过收集到的信息,选择一个日志最全的节点作为备选primary, 在提升为primary接受写服务之前,需要确保日志完全应用完,未完成的事务,从undo恢复出来,在后台进行回滚,然后才能正式提升为primary并接受写请求。其他从region的standby则指向新的primary,请求日志,对于旧region, 当其恢复可用后,由于我们已经选举了新的主库,因此其数据已经不可用,需要进行重建,并从新主库复制数据。通常在完全恢复全球数据库集群后,可能还需要进行一次计划内切换,将原可用区恢复成主region, 这取决于用户的写负载是否具有区域性

写转发

全球数据库支持写转发能力,发送到从Region的写请求,既可以通过Proxy进行写转发,也可以通过数据库内核进行写转发,这对用户客户端来说都是透明的,理论上来说,我们支持任意类型的写转发。

当写转发后,如果随后发起数据读,根据需求,可能会有不一样的一致性,这里支持三种一致性级别:最终一致性,会话一致性和全局一致性。

客户端在备库上发送一个开启事务的指令,这个指令会发送到Primary,同步的开启一个事务,随后针对三种一致性配置,可能会有不同的行为。随着用户提高一致性级别,用户的应用程序会花更多时间等待在更改在RO的回放,可以在快速响应与一致性之间选择平衡。

下一步展望 - 基于云基础设施构建云原生数据库

更彻底的云原生 :全面拥抱云基础设施,目前 TDSQL-C 不管是计算还是存储节点多为物理机部署,正进行全面虚拟化,解决小地域开区物理限制等问题。

更极致的弹性 :包括全栈 serverless 及 CPU/内存、存储解耦等,致力于提供更稳定、更优质的云数据服务。

以上内容来自冉仟元老师的分享。