加快企业级能力国产化,腾讯云数据库做了这些事情
《深入解读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全新引擎构架揭秘》
腾讯云数据库专家工程师 伍鑫
《详解列存储设计支撑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数据库的执行器中支持大部分scan、agg、join、以及cte算子等的并行执行。在此基础上,张倩团队进一步开发了向量化的执行引擎,支持scan、agg、join、以及remote subplan等算子的向量化执行,同样支持串行执行和并行执行两套执行流程。TDSQL-A数据库的向量化设计,既有批量执行的优势,又能灵活地处理短路场景,从而达到执行效率最优。
﹀
﹀
﹀
腾讯云数据库TDSQL两大引擎全新升级,分析能力和Oracle兼容能力大幅提升
连续三年!我们做到了
↓↓点击阅读原文,了解更多优惠