加快企业级能力国产化，腾讯云数据库做了这些事情

今年6月，腾讯云数据库TDSQL PG版 Oracle兼容能力以及TDSQL-A两大引擎全新升级，Oracle兼容性和海量数据查询分析能力再上新台阶。为帮助开发者更清楚的了解到腾讯云数据库究竟做了什么，特推出"DBTalk数据库企业级能力国产化”专场，就数据库引擎在Oracle兼容核心能力构建、海量数据分析引擎构架设计、下一代列式存储原理、复杂查询执行优化等方面进行深入解读。

本期带来各讲师分享精华及直播回顾视频。想要讲师ppt的小伙伴，可在腾讯云数据库公众号后台发送"610讲师课件"，即可获得哦！

《深入解读TDSQL的Oracle兼容及管控能力》

腾讯云数据库高级产品经理 李晓慧

TDSQL for PostgreSQL Oracle引擎版全新升级，支持更多的Oracle兼容特性，具有更强的管控能力，同时提供私有云和公有云两种服务方式，并且支持分布式和集中式两种架构。腾讯云数据库高级产品经理李晓慧分享的内容主要有三个方面，分别为TDSQL PG版的架构概览、Oracle兼容性和重点管控能力。

TDSQL PG版集群分为OSS管理系统和数据库实例两部分，OSS管理系统主要包含如下几个组件：

• center运维管理中心是OSS的核心部分，负责处理用户对集群的相关操作，通过OSS的WEB端下发命令到Center，再下发到各个Agent或者数据库节点执行，同时还负责定时任务的调度和执行。
• confdb是OSS的配置数据库，负责存储整个集群的元数据信息，例如节点关系等。
• etcd集群提供OSS管理系统的高可用支撑，负责OSS Center和ConfDB的选主，同时存储高可用信息。
• agent是OSS具体任务执行者，在每台物理机上安装一个，与数据库节点一起进行混合部署，每台部署了数据库节点的物理机上都需要安装一个Agent服务。OSS管理系统通过Agent实现对每个数据库节点的状态监控和操作。

TDSQL PG版提供分布式形态和集中式形态给到客户灵活选择。分布式实例包含GTM、CN、DN节点，集中式只包含DN节点。

• GTM（Global Transaction Manager）是全局事务管理，提供实例范围的统一时钟和支持分布式事务。
• CN是指协调节点，负责处理业务的读写请求，转发请求到DN，汇聚多个DN的结果。
• DN节点负责保存实例的数据。

TDSQL PG版经过多年的行业打磨，在特定行业的适配下其兼容性高达98%及以上，主要体现在接口、功能、语法和生态四个大的层面。

• 在访问接口上，我们支持JDBC/ODBC、C/C++、OCI、Python等多种访问方式，OCI我们支持100+多个常用的接口。
• 在语法上，兼容全部的内置数据类型，内置函数包含单行函数、聚合函数、分析函数在内，共计100+个；PL/SQL方面，兼容程序的定义、变量的定义、多种控制结构、动态SQL等；系统内置包兼容了常用的10多个；系统视图兼容了常用的40+个。
• 在功能上，分区表、查询、同义词、序列、rownum、rowid等多种特性都进行了兼容。
• 在生态上，我们提供了从兼容性评估、数据迁移、数据同步、数据比对、业务交割等一系列的方案。

李晓慧表示，管控系统主要是负责管理整个数据库集群，包含非常丰富的功能，它同时可以管理集中式和分布式的实例，集租户管理、服务器资源管理、实例监控运维管理于一体。从集群部署、实例生产、实例扩容、故障修复到行优化和资源回收，贯穿TDSQL整个运营生命周期。

用户在应用迁移到TDSQL PG版之后如何更容易的使用分布式数据库一直是TDSQL for PG团队致力于解决的问题，以下李晓慧着重分享了三个方面的企业级能力：

• 分布式快速扩容：能够解决传统扩容在搬迁数据时需要消耗大量时间的问题，该工具能将分布式的数据节点快速从1组扩容成2组，从而极大减少了变更的时间窗口。
• 分布式备份恢复：提供物理备份恢复和逻辑备份恢复的能力，并且能实现分布式的PITR恢复。
• 全局session视图：能够提供分布式下的执行状态树，让分布式数据库中的进程运行状态一目了然。

李晓慧讲师更多分享内容，可见下方完整视频版：

《TDSQL-A全新引擎构架揭秘》

腾讯云数据库专家工程师 伍鑫

TDSQL-A作为腾讯首款自研MPP分析型数据库，于2021年5月发布后，在政务，公安，电信，金融等多个企业级项目中崭露头角。经过团队过去一年的深入探索和改进，TDSQL-A迎来全面升级版本，腾讯云数据库专家工程师伍鑫强调在自研列式存储、向量化引擎、并行执行逻辑、计算层缓存等核心技术模块取得重大性能突破，通用场景分析性能提升十倍以上。另外对产品周边生态工具以及易用性上也持续投入，推出高速数据流转工具、查询瓶颈自动分析工具、复杂查询自动优化能力等。

伍鑫表示，TDSQL-A通过基于heap表的元数据实现，将列存的MVCC设计与行存表统一，使得TDSQL-A的列存表能够完美支持DML、分布式事务一致性、并发更新等能力。同时列存表也支持B-Tree/Hash索引，range/hash/list等多级分区表能力。用户使用起来更加方便，在选择存储类型建表后，用户基本可以无感知的进行行列混合多表关联、基于索引的点查询加速、多任务并发入库/查询。

伍鑫在分享中提到，PostgreSQL和大多通用关系型数据库一样，执行引擎选择适应性更强的标准火山模型。数据自下而上按tuple元组级别被一条条的向上流转。本次升级TDSQL-A主要聚焦向量化执行执行方向进行框架改造和深入优化。针对TPC-DS场景做到所有语句支持向量化执行。

作为通用分析型数据库，系统并不会对多表关联查询操作进行限制，用户可以自由根据业务模型进行表设计及优化，而这其中最复杂的模块非查询优化器莫属。TDSQL-A分布式优化器结合CBO与RBO对MPP分布式计算进行最佳查询计划搜寻，保证查询在TPC-DS级别的语句中，基本可以做到无需优化器参数调优，用默认参数就可以生成最佳执行计划。而在多个企业级项目的复杂（20～30张表关联）业务场景中，也得到了很好的效果验证。

伍鑫强调，TDSQL-A在本次升级后，提供了增强的资源组（Resource Group）管控能力，为角色Role提供资源组配置能力，相同资源组内用户可以设置优先级控制。资源组能力控制本身支持基于CGroup的CPU资源管控，基于query_mem的语句级内存资源管控能力。整体保证集群CPU、内存等资源完全在内核范围可控，避免因复杂查询导致系统资源耗尽带来的异常状况。用户可以基于资源组支持多租户能力，灵活进行业务资源隔离。

TDSQL-A海量数据处理情况下，PostgreSQL原生的Copy数据导入性能成为瓶颈，如何快速将前端OLTP/ODS数据导入到TDSQL-A进行分析成为了整个生态中关键的一环。这里我们针对分析型数据库多DN节点进行了分布式优化，用户建立基于TDX（TDSQL-A Data Exchanger）的外部表，在数据导入导出过程中，DN并行的从TDX进行数据分片的收取和发送，整体性能达到Copy的数十倍。

伍鑫讲师更多分享内容，可见下方完整视频版：

《详解列存储设计支撑HTAP场景》

腾讯云数据库高级工程师 吕夫洋

关于TDSQL-A列存储的底层架构设计，以及这些设计是如何支撑传统的分析性数仓场景以及HTAP混合负载场景的，腾讯云数据库高级工程师吕夫洋在本次分享中给出了答案。

吕夫洋的分享主要分为三个部分，数据库存储引擎背景，存储引擎基础架构设计以及重要组件以及混合负载业务场景以及引擎内部机制。

行存储引擎交每行的数据连续的存储在一起，对于交易性业务、也就是OLTP这样频繁以行作为单位存储表中数据的业务负载，行存储性能比较好，适合于交易型和点操作。但是，吕夫洋重点提到对于分析性业务，使用行存储会将当次查询不相关的列数据读入内存中，会带来额外的系统资源开销。使用列存储模型通过将表中的列连续的存储在一起，能够很好的解决这个问题，且在对大数据量的范围操作或者复杂查询场景下有着优异的表现。

如果一个系统中需要同时承载交易性和分析型两种混合的业务负载，一般简称HTAP，针对OLTP优势的传统的行存与针对OLAP优势的列存都无法很好单一的同时应对两种类型。吕夫洋表示，业界实现往往无法避免以下问题：需要额外的系统资源（存储资源、计算资源）、难以兼顾数据的实时性和强一致性、业务需要对存储进行感知。

带着使用一套存储、一套资源，来同时满足混合业务负载的目标，吕夫洋及其团队设计了TDSQL-A的新存储引擎，Effective_Storage_Engine,简称Estore。Estore引擎中一张Estore表主要由三部分组成：

• Silo是Estore的存储数据的单位，也是处理的最小单位。每个Silo包含一组数据（默认65535行）中其中一列的数据，方便系统对其进行批量操作、压缩、存储。Silo是一个完全自描述的存储单元，Silo头部独立存储了Silo数据相关的读取与解析信息，因此也允许Silo可以根据自身的数据类型、数据特征以及表级别/列级别指定使用对应的压缩算法，选择针对自身数据特征最合适的压缩算法或压缩算法的组合。
• registry表作为Estore表的元信息表，是Estore表的主体组织结构。registry每一行对应一个存储单元Silo进行元数据管理，即为一个 Silo 的“代理”，存储其元信息、预处理信息、以Silo的存储位置信息。
• Stash表是Estore表创建后同步创建的一张行存表，与原表有着相同的表定义，但使用行存表作为存储。Stash表的作用为充当Estore表的“临时区“角色，针对单次行数在一定阈值下的操作，其相关数据会先行被放入Stash表中，以行存储的形式存储起来，一方面应对碎片化冲击，保证registry/silo存储以及相关机制的高效运作。同时，由于放在Stash表中的都是近期单条/小批量插入或更新的数据，Stash表也就在实际上起到了Estore表类似“热数据分片”的概念。

在混合负载场景中，吕夫洋用两种比较常见的场景来举例说明混合负载场景中引擎内部的作用。

一种是碎片化的增量数据，即非bulkload方式将数据供给到数据库内核。单个事务内新增行数或者数据量涉及少，单操作次数频繁。这种情况下，Estore表的Stash 回优先承载碎片化数据，然后统一批量合并至 Silo 存储，避免碎片化数据对 Silo 产生直接冲击。

又比如用户可能选择使用一套系统，在日间其业务高峰时间处理正常的交易型业务负载，在夜间或凌晨业务低峰期在同一套系统中针对相关数据或全量历史数据产生报表或进行进一步 BI 分析。

在主要以交易型业务负载下，引擎内部面对短事务新增的数据以及从临时数据中点更新的数据的新版本，数据自动的流向了Stash表，整体业务负载集中在Stash表的行存储结构上；

在夜间或者凌晨进行跑批、报表和统计的业务负载下，经过批量操作以及配置呢，数据由stash自动的流向silo，由silo的存储结构来承载复杂的分析型业务查询，利用silo批量、压缩、元数据过滤以及各类加速的能力，并提供很好的批量操作以及很多性能优化。

吕夫洋讲师更多分享内容，可见下方完整视频版：

《大数据场景下的复杂查询执行优化》

腾讯云数据库专家工程师 张倩

腾讯云数据库专家工程师在分享中提到了TDSQL-A数据库的分布式架构中有三种节点：协调节点CN，用来接收用户发过来的查询；数据交互节点FN，用来做数据交换；数据存储节点DN，用来存储业务数据。其中，CN的主要职责是接收查询并生成一个全局的查询计划，根据查询计划创建DN执行进程，下发对应的计划分片，并在执行过程中管控各个执行进程，返回最终的查询结果。FN节点的职责是负责DN之间、以及CN和DN之间的数据传递，DN节点的职责是执行CN下发的计划分片。

张倩表示，基于这样的分布式架构，TDSQL-A数据库的优化器采用分布式的计划策略，包含两个方面：

第一是正确性，在不同的数据分布情况下，优化器应该选择一个正确的数据重分布方式，来保证计算结果的正确性；

第二是代价最优，在正确性的前提下选择一个性能最优的数据重分布方式。

张倩强调，除了分布式计划策略，优化器还采用并行的计划策略。并行执行具有一定的额外代价，优化器会根据代价来选择不同的并行策略，包括是否开启并行和选择并行worker数。基于代价模型，结合分布式和并行的计划策略，优化器在计划分片内根据代价来选择不同的并行策略，在计划分片间解耦并行策略。在这基础上，优化器进一步支持向量化的计划策略。针对HTAP场景，支持行列混合的计划和执行，其中行处理和向量化可以互相转换。基于代价模型，在并行、分布式和向量化计划策略的基础上，优化器综合考虑各方面因素，生成一个全局代价最优计划。

对于并行计划，执行器中会由gather、gathermerge以及remote subplan算子来负责启动并行执行，包括启动执行worker、子查询执行、还有执行worker的管控等。此外remote subplan算子还支持并行的数据收发，同时支持上下层计划分片的并行执行解耦。

并行执行的设计包含两个原则，一是支持共享的数据处理，二是支持不确定的、随机的数据处理。当前TDSQL-A数据库的执行器中支持大部分scan、agg、join、以及cte算子等的并行执行。在此基础上，张倩团队进一步开发了向量化的执行引擎，支持scan、agg、join、以及remote subplan等算子的向量化执行，同样支持串行执行和并行执行两套执行流程。TDSQL-A数据库的向量化设计，既有批量执行的优势，又能灵活地处理短路场景，从而达到执行效率最优。

最后，张倩分享了TDSQL-A数据库的SQL引擎全面优化表现在，在优化器方面，基于代价估算，结合分布式、并行、子查询优化、向量化等策略，生成一个全局最优的查询计划；在执行器方面，优化整合分布式、并行以及向量化执行，进一步提升查询执行性能，实现通用场景下查询性能较上一版本的十倍提升。

张倩讲师更多分享内容，可见下方完整视频版：

﹀

﹀

﹀

-- 更多精彩 --

腾讯云数据库TDSQL两大引擎全新升级，分析能力和Oracle兼容能力大幅提升

连续三年！我们做到了‍

↓↓点击阅读原文，了解更多优惠