TCE-OS-007-054 腾讯专有云 产品白皮书 分布式云数据库(Tbase)V3.4.2

腾讯专有云TCE Tencent Cloud Enterprise

分布式云数据库TBase

产品白皮书

前言

【版权声明】

?2013-2020 腾讯云版权所有

本文档著作权归腾讯云单独所有，未经腾讯云事先书面许可，任何主体不得以任何形式复制、修改、抄袭、传播全部或部分本文档内容。

【商标声明】

及其它腾讯云服务相关的商标均为腾讯云计算（北京）有限责任公司及其关联公司所有。本文档涉及的第三方主体的商标，依法由权利人所有。

【服务声明】

本文档旨在向客户介绍腾讯云全部或部分产品、服务的当时的整体概况，部分产品、服务的内容可能有所调整。您所购买的腾讯云产品、服务的种类、服务标准等应由您和腾讯云之间的商业合同约定，除非双方另有约定，否则，腾讯云对本文档内容不做任何明示或模式的承诺或保证。

【修订记录】

01 2020-01-30 amyleali 第一次发布。

目录

前言 (2)

目录 (4)

1.发展历史 (9)

2.业务挑战 (11)

2.1.业务迁移便利性 (11)

2.2.分布式事务一致性 (11)

2.3.服务高可用 (11)

2.4.集群可扩展能力 (12)

2.5.数据高安全保证 (12)

2.6.HTAP-事务以及分析双引擎支持 (12)

3.腾云HTAP数据库TBase解决方案 (13)

4.产品核心功能 (15)

4.1.SQL兼容度高 (15)

4.1.1.兼容PostgreSQL语法 (15)

4.1.2.兼容Oracle语法 (15)

4.1.3.企业级数据库语法支持 (16)

4.2.分布式事务全局一致性 (17)

4.2.1.TBase的分布式事务全局一致性实现 (17)

4.2.2.TBase分布式事务可靠性保证机制 (18)

4.3.在线扩容能力 (19)

4.4.HTAP事务及分析双引擎方案 (22)

4.4.1.概述 (22)

4.4.2.如何进行OLTP以及OLAP融合查询 (22)

4.4.3.如何进行高效的分布式join (23)

4.4.4.行列混合存储能力 (26)

4.4.5.多核并行计算能力 (27)

4.5.多级容灾能力保证 (31)

4.5.1.容灾能力概述 (31)

4.5.2.强同步复制 (31)

4.5.3.故障自动恢复与转移 (31)

4.5.4.基于时间点的恢复能力 (32)

4.6.资源隔离能力-读写多平面 (34)

4.7.卓越的数据安全保障能力 (34)

4.7.1.三权分立体系 (35)

4.7.2.数据存储加密 (37)

4.7.3.透明数据脱敏 (38)

4.7.4.强制访问控制 (39)

4.7.5.全方位审计能力支持 (40)

4.8.高效的数据治理能力 (41)

4.8.1.概述 (41)

4.8.2.数据倾斜解决方案 (41)

4.8.3.冷热数据分级存储方案 (44)

4.9.1.简单易用的TBase运维管理系统 (45)

4.9.2.集群PASS平台能力支持 (45)

4.9.3.运维系统亮点功能 (46)

4.10.丰富的周边生态支持 (47)

4.10.1.支持强大的GIS地理信息系统 (47)

4.10.2.异构数据复制能力 (48)

4.10.3.集群负载均衡能力 (49)

4.10.4.JSON数据类型的支持 (50)

4.10.5.强大的联邦数据库能力 (51)

5.专有云方案简介 (52)

5.1.部署架构与软件模块 (52)

5.1.1.核心模块 (52)

5.1.2.选配模块 (53)

5.2.操作系统要求 (53)

5.3.物理服务器机型配置建议 (53)

5.3.1.功能测试配置 (53)

5.3.2.性能测试配置 (55)

5.3.3.最小规模配置 (57)

5.3.4.服务器采购参考 (58)

5.3.5.服务器采购参考 (61)

5.3.6.单中心容灾部署建议 (61)

5.4.1.同城双中心部署建议 (62)

5.4.2.两地三中心部署建议 (62)

5.5.TBase对接腾讯专有云平台（TCE） (63)

5.6.TBase对接腾讯企业云平台（TStack） (63)

6.TBase产品特有优势 (65)

6.1.HTAP融合性数据库 (65)

6.2.完全保障分布式全局事务一致性 (65)

6.3.支持多级安全策略 (65)

6.4.完备的运维管理系统支持 (66)

7.产品资质 (67)

8.典型应用场景 (68)

8.1.HTAP业务需求系统 (68)

8.2.物联网地理信息系统 (68)

8.3.实时高并发事务系统 (68)

8.4.海量存储计算需求 (69)

8.5.数据高安全依赖型系统 (69)

8.6.去O的最佳选择 (69)

8.7.多点汇聚业务系统 (69)

9.典型案例分享 (71)

9.1.某省办事系统核心OLTP后台系统 (71)

9.2.某省公安厅汇聚库建设 (71)

9.4.东阳人民医院 (73)

9.5.许继电器（智能电表物联应用） (73)

9.6.微信支付商户订单系统 (74)

10.附录 (75)

10.1.通用约定格式 (75)

10.2.功能术语表 (75)

1.发展历史

大数据时代的来临以及去IOE浪潮的兴起，大众的目光都投向了开源的系统，基于开源PostgreSQL扩展而来的tPG(tencent PG)系统作为腾讯商业数据库的替代方案，同时作为腾讯大数据平台TDW（Tencent Distributed Warehouse）的实时数据库组件2011年正式引入公司内部使用。

经过这这些年的大规模的使用，目前服务器规模达到上千台，接入业务涉及了几乎公司内所有BG，为公司业务提供了更多关系型数据库选择，tPG也成为公司内最大的PostgreSQL实践场地。通过这些年的运营，团队积累了丰富的实践经验以及应用场景。

伴随着腾讯业务的快速发展，游戏、广告、微信等业务单机tPG实例纷纷遇到了瓶颈，诸如存储和性能无法扩展，业务拆分难度大，在此背景下，TBase团队从2013年起开始分布式数据库集群化的探索，通过详细的前期测试，综合tPG上的场景，我们决定从OLTP场景入手，走自研的路线，在2015年，TBase数据库集群应运而生，不鸣则已，一鸣惊人，微信支付商户系统在这一年成功的从业务分库分表的模式中迁移到了TBase分布式集群里，通过自动化sharding的方案帮助业务解降低了分库分表带来的业务开发复杂度、通过独创性的冷热分区的方案降低了业务的使用成本、灵活的扩容方案应对业务的快速增长。

伴随着腾讯云逐步把公司内部的能力开放给外部客户，TBase在这个过程中也接触到了更多的外部企业客户，越来越了解到数据安全、HTAP全功能能力的需求十分旺盛，TBase产品经过不断迭代，强化了企业级安全特性、列存储、压缩、读写分离，资源隔离等多方面的能力，TBase数据库集群也在这个基础上发布了。TBase凭借着产品的卓越竞争力，截止到2019年3月，已经在银行、保险、证券、微信支付等多个行业提供底层数据库支撑。

2.业务挑战

2.1.业务迁移便利性

在很多应用场景中，都是老单机数据库系统无法承载数据量的增长以及业务的发展，需要进行业务迁移，那么在数据库选型中，业务迁移的便利性就成了一个很重要的指标。TBase在协助业务迁移这个层面提供了诸多有意义的特性以及功能支持，简单列举如下：

?TBase实现了SQL 2011标准所规定的大部分功能，除了基础的SELECT、UPDATE、INSERT、JOIN、GROUP BY等功能，还支持外键约束、check、主键、触发器、视图、存储过程、多级事务、多版本并发控制等高级功能。

?TBase的SQL语法完全兼容PostgreSQL，同时也兼容相当大一部分Oracle语法，限制降低了PostgreSQL以及Oracle用户的迁移成本。

?TBase提供异构数据库迁移工具，高效可靠的将老的业务系统数据迁移至TBase中。

2.2.分布式事务一致性

对某些业务（如金融业务）来讲，数据的强一致（Consistency）尤为重要。如果出现数据丢失，就意味会给组织或用户带来直接的金钱方面的损失，甚至影响企业的商誉和信誉。因此，数据的一致性是数据库设计中最需要考虑的问题之一。

另外一方面，相对于传统的单机数据库，分布式环境下的事务一致性是分布式数据库的重大挑战，网络时延和操作系统调度等不确定因素给分布式事务一致性的保证带来诸多困难，但是分布式数据必须有一套完整的分布式事务一致性逻辑，否则会带来灾难性的后果。

2.3.服务高可用

在线服务的高可用能力是衡量一个系统好坏的最重要的指标之一，因此构建7*24小时服务能力是系统在构

建之初就必须考虑的问题，如果不能做到这点，那么用户体验就会特别差，带来的后果就是客户的流失、企业形象的负面影响、甚至是企业利润的降低。

2.4.集群可扩展能力

在当今互联网时代，业务量会不断增长。另外一个方面，系统在一年之中也有请求量的高峰，在集群构建之初，很少能按照业务的最大规模来采购硬件设备，主要是因为（1）业务的最大规模很难预估；（2）如果按照最大规模来进行采购，这样会带来极大的资源浪费。另外一方面，数据库集群的可扩展能力可以给业务开发带来很多便利性，业务系统无需顾虑太多，免去了很多开发焦虑。集群可扩展能力也包括在集群扩容的时候对业务基本无影响。

2.5.数据高安全保证

数据安全之余信息安全，是一个企业的命脉，安全是系统建设的头等大事，一旦数据发生泄露，那么付出的代价将是非常惨痛的。由于数据泄露而导致的业务中断、客户信心丧失、法律成本、监管罚款，这些后果可能需要花费数百万甚至灾难性的。

2.6.HTAP-事务以及分析双引擎支持

在数据库系统应用中，OLTP场景涉及数据量小，但是要求实时返回，OLAP类场景涉及的数据量、计算量大，但是对实时性要求没那么高。通用的方案是业务做拆分，将OLAP与OLTP场景分别用对应的系统来支撑，这样解决了性能问题，但是这样带来了存储成本的上升以及业务高昂的改造成本，同时在系统间数据同步容易造成数据出错等种种问题。因此一套系统里能同时覆盖OLTP以及OLAP场景是业务对数据库系统的一个很重要的诉求。

3.腾云HTAP数据库TBase解决方案

TBase是腾讯云数据库团队维护的HTAP分布式数据库集群，目前提供专有云部署方案，计划在2019年下半年提供公有云服务。TBase是一款高扩展性、SQL兼容度高（兼容绝大多数PostgreSQL语法以及大部分Oracle语法）、提供分布式全局事务一致性功能支持、具备多级容灾能力以及多维度资源隔离能力的高安全性的企业级HTAP分布式数据库集群产品，获得多项国际以及国家认证，并在多个行业有广泛应用。TBase采用分布式集群架构（如下图），该架构分布式无共享(share nothing)模式，节点之间相应独立，各自处理自己的数据，处理后的结果可能向上层汇总或在节点间流转，各处理单元之间通过网络协议进行通信，并行处理和扩展能力更好，这也意味着只需要简单的x86服务器就可以部署TBase数据库集群

下面简单解读一下TBase core的各个模块。

?Coordinator：协调节点（简称CN），对外提供接口，负责数据的分发和查询规划，多个节点位置对等，每个节点都提供相同的数据库视图；在功能上CN上只存储系统的全局元数据，并不存储实际的业务数据。

?Datanode：处理存储本节点相关的元数据，每个节点还存储业务数据的分片，简称DN。在功能上，DN节点负责完成执行协调节点分发的执行请求。

?GTM:全局事务管理器(Global Transaction Manager)，负责管理集群事务信息，同时管理集群的全局对象，比如序列等。

在这个架构下，TBase集群具有下面几个能力：

?多活/多主：每个coordinator提供相同的集群视图，可以从任何一个CN进行写入，业务无需感知集群拓扑；

?读/写扩展：数据被分片存储在了不同的DN，集群的读/写能力，随着集群规模的扩大做而得到提升；?集群写一致：业务在一个CN节点发生的写事务会一致性的呈现在其他的CN节点，就像这些事务是本CN节点发生的一样；

?集群结构透明：数据位于不同的数据库节点中，当查询数据时，不必关心数据位于具体的节点；TBase的share nothing集群架构方便了业务接入，降低了业务接入的门槛。

4.产品核心功能

4.1.SQL兼容度高

一款数据库产品是否能称之为企业级产品，SQL支持能力是一个非常重要的衡量指标。TBase在SQL兼容性上具备很大的优势，不仅兼容绝大多数的PostgreSQL语法，包括复杂查询、外键、触发器、视图、存储过程等等，满足大部分企业用户的诉求。同时TBase还兼容大部分的Oracle类型、函数，这个特性很方便Oracle业务很容易的迁移到TBase数据库中。

4.1.1.兼容PostgreSQL语法

TBase与PostgreSQL一样实现了SQL 2011标准所规定的大部分功能，除了基础的SELECT、UPDATE、INSERT、JOIN、GROUP BY等功能，还支持外键约束、check、主键、触发器、视图、存储过程、多级事务、多版本并发控制等高级功能。

在数据类型上，TBase除了支持常见的数字、字符串，时间类型，还支持自增序列、货币、几何、UUID、Array、JSON、Range等类型。

在接口上，TBase支持JDBC/ODBC/shell/C/Python/PHP/.NET等大多数语言的API。

用户完全可以像使用单机PostgreSQL一样使用TBase，无需额外的学习成本。

4.1.2.兼容Oracle语法

TBase作为去O的最佳选择之一，在很多企业级的特性就支持十分完善，包括复杂子查询、存储过程、窗口函数等。为了进一步降低业务代码迁移改造的工作量，在内核级就做了很多Oracle语法以及函数的支持，使得业务代码几乎不用进行改写或者只用进行极少的改写就可以运行在TBase上，实现业务的快速迁移。

4.1.3.企业级数据库语法支持

式事务、分布式JOIN。原生支持整数、浮点数、字符、time、date、datetime、bytea(二进制)、数组、Json、Jsonb、XML、uuid、GIS（几何类型点，线，面），复合、范围以及全文搜索等数据类型，支持自定义数据类型。

4.2.分布式事务全局一致性

一致性是分布式事务中的重大挑战，网络时延和操作系统调度等不确定因素给分布式事务一致性的保证带来诸多困难，但是分布式数据必须有一套完整的分布式事务一致性逻辑，否则会带来灾难性的后果。4.2.1.TBase的分布式事务全局一致性实现

TBase引入全局事务管理节点（GTM，Global Transaction Manager）来专门处理分布式事务一致性，通过拥有自主专利的分布式事务一致性技术，包括两阶段提交（Two Phase Commit）以及全局时钟（Global Timestamp）的策略来保证在全分布式环境下的事务一致性。另外一方面，由于GTM是TBase集群中负责处理事务信息的模块，它的处理上限直接影响到系统事务处理能力的天花板，针对这个潜在的问题，采用了如下技术来解决这个问题：

?网络带宽的优化，取消系统的集群快照，改为逻辑时钟来判断事务的集群可见性，大幅减少对GTM 的网络带宽的占用，同时还降低了GTM的CPU占用。

?CPU使用率的优化，通过线程资源复用的方式大大减少GTM的线程数据，减少系统调度CPU占用率，大幅的提升GTM的处理效率。

?系统锁的优化，在系统吞吐量达到百万级时GTM原来使用的系统互斥锁占用了绝大多的CPU，我们编写了用户态的互斥锁，使得CPU使用率只有原来的十分之一，提升了系统的处理能力上限。

?免锁队列的使用，使用免锁队列取代原来的带锁队列，减少系统的锁使用，大幅提升系统的处理效率。

通过上面的这些优化，TBase单机群的TPCC事务处理能力得到大幅度的提升，而且处理能力会随着集群规模准线性提升。下面是我们在60台集群规模下测试的tpcc结果，最大吞吐量达到310W每分钟，此时系统DN,CN资源吃紧，但是GTM资源仍有相当多的剩余，因此随着集群规模的增加，系统的吞吐量还可

以继续提升。

4.2.2.TBase分布式事务可靠性保证机制

前文提到过分布式事务如果处理不好，将会对整个系统带来灾难性的后果，针对TBase所采用的两阶段提交策略，主要会有以下几个潜在的问题：

?资源阻塞问题：残留的存在prepare状态的两阶段事务仍然持有一些资源锁，这将会阻塞之后对部分数据的访问和更新操作。

?数据不一致问题：数据不一致问题集中体现在第二阶段的故障场景中。当两阶段提交事务出现了部分commit部分prepare，那么更新数据在部分commit的节点可见；当两阶段提交事务出现了部分commit部分rollback，那么数据在所有节点出现了不可恢复的不一致状态。

?协调节点宕机问题：当出现协调节点宕机的情况，即便是有做了主备倒换，产生了新的协调节点，参与节点中的异常两阶段事务将一直残留下来。

针对这些潜在的异常问题TBase在内核处理机制以及异常处理两个角度来确保不会出现上述问题。

?首先内核处理机制上：这个部分我们做了两件事，第一，在两阶段事务执行过程中记录信息，用于恢复

残留两阶段事务；第二，避免进入“Commit Prepared”的两阶段事务在所有参与节点回滚该事务。?其次在异常处理上：TBase提供了一个两阶段事务的自动处理工具，在系统监测到残留的2PC事务时，运行工具来处理系统的两阶段事务，保证业务的正常运行。通过访问残留两阶段事务的信息，来判断其在各个参与节点中的状态，根据事务的全局状态，我们对其进行异常事务清理，最终使得数据恢复至全

用。

在HASH分布的情况下，通过如下方式决定一条记录的存储节点：

DN = Hash(row) % nofdn

也就是说先对分布列计算hash值，然后使用这个值对集群中的节点个数取模来决定记录去哪个节点。这里有一个问题，扩容后节点数会变多，数据分布的计算逻辑就会导致已经存在的数据无法正常访问。为了解决这个问题，就必须把业务停掉，把所有数据导出，扩容后重新导入，在数据量较多时，这个过程会持续几天，