强大互联网基因，深度揭秘腾讯云新一代企业级HTAP数据库TBase

作者简介：李跃森，腾讯云资深数据库专家，大数据专家，PostgreSQL社区成员，负责TBase数据的架构设计和技术研发，超过10年的数据库内核设计开发经验，参与并完成多种数据库的架构设计和开发。

2017年年底，腾讯云PostgreSQL-XZ（PGXZ）正式改名为TBase，目前已经应用于政务、公安、消防、电信、金融等行业的十几家客户中。TBase以其功能强大，运行稳定以及强大的互联网基因得到客户的普遍认可。

2016年，基于腾讯云内外的需求变化，TBase的HTAP方案开始预研，目前已应用在包括微信支付等多个客户中。2018年4月，TBase的HTAP方案（将正式对外发布。

TBase核心概念：

Tbase的重要的技术特性和概念，主要包括以下几个方面：

企业级：

企业级特性包含以下几个方面：

• 用户友好的事务特性：业务无需关注数据库的事务特性，数据库内核支持完整的分布式事务，保证事务的ACID。

• 用户友好的数据库特性：主键，外键，序列，约束，分区表，存储过程，触发器，子查询等企业级的特性完整支持。

• 用户友好的SQL接口：当前Tbase能够兼容SQL2003标准，同时还能够兼容常见的ORACLE语法，可以方便ORACLE深度用户的迁移，当前在外部已经有ORACLE迁移的案例。

• 用户友好的分布式查询能力：良好的分布式查询支持能力，数据库内核能够高效的处理分布式JOIN。

• 高效的在线线性扩容，在集群规模发生变化的时候不会影响到业务的运行。

HTAP能力：

Hybrid Transactional/Analytical Processing，即事务和分析混合处理技术，这个技术要求本来资源诉求矛盾的两种业务类型在同一个数据库中完成处理。

Tbase经过专门的设计完美的做到了HTAP，同时具备了高效的OLAP能力和海量的OLTP处理能力。

下面是我们测试的事务测试模型TPCC的benchmark测试结果，系统在每分钟完成的事务量超过310万，更大规模集群的测试还在进行中。从当前的架构设计来看，在硬件允许的情况下，系统的事务吞吐量会随着集群规模准线性提升：

下面这张图展示了TBase在行存储模式下和业界MPP数据仓库标杆在OLAP测试集合TPCH 1T benchmark下的对比情况：

通过这张图可以直观的看到TBase的OLAP分析能力，TBase在22个用例中每个用例的耗时都优于Greenplum，部分用例耗时大幅度的超过Greenplum。

通过HTAP技术，业务可以在单一的TBase集群中同时处理OLTP类交易和OLAP类分析。通过HTAP，可以大幅度的减少业务系统的复杂度，降低运维成本。

高数据安全：

在和客户交流的过程中，多个行业的客户都提到了数据安全的诉求，TBase团队结合客户的需求和业界先进的数据库安全解决方案设计了Tbase的数据安全体系。这个体系主要包含以下几个方面：

• 三权分立：把数据库系统dba的角色分解为三个相互独立的角色，安全管理员，审计管理员，数据管理员，这个三个角色之间相互制约，消除出系统中的上帝权限，从系统角色设计上了解决了数据安全问题。

• 强制安全规则：结合业界先进的数据库安全解决方案，Tbase提出了强制安全规则解决方案，通过安全管理员制定的强制安全规则，可也做到行级可见和列级可见，进而限制用户看到的数据，对不同的用户做到权限的行列混合控制，有效的杜绝数据越权查看，保证关键数据的安全性。

• 透明数据脱敏管理：对于金融，安全等对数据安全有特殊要求行业，经常会有数据脱敏的诉求，但是现有的解决方案很多都需要有业务的参与，要求业务深度的参与，有一定的门槛。TBase针对这个痛点进行了专门的设计，做到业务的透明脱敏，业务只需要根据自己的业务规则结合TBase的脱敏语法，设计业务逻辑。TBase内部就可以做到数据的脱敏，同时结合上面提到的强制安全规则，安全管理员可以做到指定数据脱敏的针对用户，最终达到高安全级别的用户看到的是非脱敏的数据，低安全级别的用户看到的是脱敏后的数据。

• 审计能力：在与客户交流的过程中，众多客户都提到了数据库审计的诉求，Tbase在设计的过程中，结合业界标杆的审计标准设计了自己的审计系统，在内核中实现了审计的核心功能，做到在兼顾高精准的审计粒度的同时还能保证系统的性能。同时针对一些业务中遇到的问题，设计专门的解决方案，做到审计结果的实时通知。

多租户能力：

TBase提供集群级和集群用户级两个级别的多租户能力。通过集群级的多租户能力，可以帮助业务快速的建立一个数据库私有云，帮助客户快速提供基于TBase的DCDB（分布式数据库）服务。集群级的多租户能力架构如下图：

除此之外，TBase数据库集群内部还提供基于节点组node group的集群内多租户解决方案，做到数据库集群内部的业务和资源隔离，多个业务在Tbase内部相互隔离的运行。下图APP1，APP2，APP3同时在一个数据库集群内部运行，相互之间通过group进行隔离，互不影响。

TBase产品架构：

上面总体上介绍了Tbase的技术特性，第一次接触TBase的同学还是有点不明所以，为了方便小伙伴们的理解后面的内容，这里把TBase整体架构介绍下。老版本和新版本在整体架构上是类似的：

集群中有三种节点类型，各自承担不同的功能，通过网络连接成为一个系统。这三中节点类型分别是：

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

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

• GTM:全局事务管理器(Global transaction manager.)，负责管理集群事务信息，同时管理集群的全局对象，比如序列，除此之外GTM上不提供其他的功能。

通过上面的架构，TBase提供了一个具有友好接口的数据库集群。这个数据库集群架构上具有如下优点：

• 写可扩展 (Write-scalable )：可以部署多个CN，并且同时向这些节点发出写操作。

• 多主节点 (Multi-master )：系统的每个CN节点都可以发起写入操作，并都可以提供统一完整一致的数据库视图；

• 数据自动同步（Synchronous)：对于业务来说，在一个CN节点的写入操作会立刻呈现在其他的CN节点上；

• 数据透明（Transparent）：是指数据虽然存在于不同的DN节点中，业务在通过CN查询数据库时，还是可以像使用普通的数据库一样编写SQL语句，不必关心数据位于具体的节点，TBase数据库内核自动完成SQL的调度执行，并保证事务特性。

TBase特性详解

OLAP能力提升：

说到OLAP能力的提升，首先要讲下TBase 老版本和在处理OLAP类请求时的差异，老版本和在处理OLAP请求时的差别主要有执行方式和DN节点之间是否相互通信两个方面：

执行方式：老版本中执行OLAP类请求时CN下发到DN的是SQL语句，DN负责SQL语句的规划和执行，然后向CN上报结果，CN完成结果的汇总。CN收集集群的统计信息，对OLAP类的查询规划集群级的分布式查询计划，并下发到各个DN上进行执行，也就是说CN下发的是执行计划，DN只负责执行而已。

DN之间是否交换数据：老版本中，DN之间相互没有通信通道，无法进行数据交换。版本在DN节点之间建立了高效数据交换通道，可以高效在DN节点之间交换数据。

差异如下图所示：

在 OLAP框架的基础上，我们开发了一整套完整高效的多线程数据传输机制，在运行OLAP查询时，这套框架保证数据可以高效的在节点之间完成同步，大幅的提升OLAP处理效率。

在算法层面，基于PG10具备的多核并行执行能力，我们在集群环境下系统性的重新设计了常用的JOIN、AGGRATE算法，得以充分发挥现有硬件的性能，在同样的集群规模下，测试OLAP benchmark TPCH 1T，平均性能超过业界标杆Greenplum 2到5倍。

OLTP能力优化提升：

GTM是TBase集群中负责处理事务信息的模块，它的处理能力直接决定了系统的事务吞吐量。而且GTM是系统中唯一的单点，它的处理上限直接影响到系统处理能力的天花板。

为此我们对GTM进行了专门的优化和设计。主要集中在以下四个方面：

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

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

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

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

除此之外我们还提出了具有专利的分布式事务一致性技术，来保证在全分布式环境下的事务一致性。通过上面的这些优化，TBase单机群的TPCC事务处理能力得到大幅度的提升，而且处理能力会随着集群规模准线性提升。下面是我们在60台集群规模下测试的tpcc结果，最大吞吐量达到310W每分钟，此时系统DN,CN资源吃紧，但是GTM资源仍有相当多的剩余，因此随着集群规模的增加，系统的吞吐量还可以继续提升。

TBase HTAP处理能力：

在讲TBase的HTAP能力之前，先分析下当前市面上主流分布式数据库架构在HTAP方面的能力，我们这里不讨论诸如Exadata、HANA之类的一体机解决方案。

首先讲下在互联网公司常见的sharding分布式架构：

这种架构通过物理上的分库分表把多个单机数据库实例使用中间件提供统一的数据库访问接口，达到分布式数据库的效果。这种架构在处理简单的SQL请求时具备一定的竞争力，但是对于处理复杂的分布式join和子查询等复杂SQL往往力不从心，因此不太擅长从事HTAP类的业务处理。

第二种架构，经典的MPP架构，典型的产品是Pivotal Greenplum，这种架构中只有一个单Master节点，使用主用数据节点提供查询服务，该架构为OLAP而生，因为单Master的问题，系统的处理能力受限于master的处理能力，而且系统锁最小粒度为表级，直接影响到事务的处理能力，这种架构只适合用来处理OLAP类业务，不适合处理OLTP类业务。

上面讲了share nothing的架构，后面分析下share everything架构，这个架构如下：

典型的产品有Sybase IQ、Oracle RAC。Sybase IQ作为一款经典的数据仓库产品，曾经风靡一时，现在数仓的很多概念和解决方案在Sybase IQ中都能找到实现，由于在设计之初就定位为一个数据仓库产品，因此架构上没有考虑处理事务类请求，只能用来处理OLAP类请求。

对于ORACLE RAC，作为当前还是很火的数据库产品，在处理OLAP和OLTP请求方面都有不错的表现，但是因为本身以及配套硬件昂贵的价格和扩容时复杂而冗长的流程，被很多的客户抱怨。

分析完了业界的解决方案，基本得出一个结论，我们需要一个可以同时高效处理OLTP和OLAP业务，而且兼顾易用性和低成本的HTAP分布式解决方案，现有的解决方案很难满足我们的需要。除了基本的能力，还有一个需要注意的问题是，OLTP类请求关注时延和吞吐量，而OLAP关注时延，两者因为关注点的不同在资源使用模型上完全不同，因而如何在同一个集群内部同时高效处理这两种业务并很好的做到资源隔离成为一个棘手的问题。

TBase团队在综合考虑了以上的各种因素后，仔细的设计了TBase的HTAP解决方案，整体架构如下：

TBase把HTAP分为两种场景：

CASE 1，OLAP和OLTP访问不同的业务数据，在这个场景下，我们可以使用TBase的group隔离技术，在天然满足物理隔离的基础上让TBase分别发挥高效的OLAP和海量OLTP能力。

CASE 2，OLAP和OLTP访问相同的数据，在同样一份数据上需要同时进行OLTP和OLAP两种操作，而且还需要同时保证两者的效率。此时为了达成资源的隔离，TBase使用DN主机运行OLTP业务，使用专门的OLAP备DN节点运行OLAP业务，达成天然的资源隔离的效果。

TBase 安全架构介绍：

TBase团队在和客户交流的过程中，多个行业的客户都对数据安全提出了诉求，TBase针对业务的痛点并结合数据库行业领先的数据库理念设计了TBase的安全体系。

TBase数据安全体系以数据库三权分离为基础，把传统DBA的权限分解为安全管理员，审计管理员，数据管理员。在安全规则领域针对安全管理员增加了安全规则和数据透明脱敏规则，在审计方面结合业界审计标准和业务的场景需要，增加了对象审计，用户审计，以及细粒度审计。除此之外的数据管理员则履行之前DBA的数据管理和数据库运维职能。

TBase 多租户能力：

TBase作为一个企业级的分布式数据库，还提供了企业常常用到的多租户能力，让客户可以在一个数据库环境运行多个业务，TBase负责多个租户之间的隔离，做到业务之间的相互无影响。

TBase的多租户整体架构如下：

TBase的多租户管理分为三个层级，最底层是资源管理层，这一层管理基础的物理机，并对物力进行资源切片和池化以及各个分片之间的隔离，同时还负责对上层的资源分配和释放。

第二层是租户管理层，这一层负责租户内部的权限管理，每个租户内部都有一个完整的三权分立体系，每个租户可以对应多个项目，每个项目对应一个集群，集群对物理资源的存放位置不感知。每个租户只可以看到自己相关的项目和集群。

最上面一层是系统管理，这一层负责租户和集群的创建，并管理整个平台的资源分配和释放，这一层可以看到整个平台的租户和集群，以及物理机的状态信息。

在系统提供的集群级多租户外，在单个TBase集群内部，还提供了基于节点组的集群内部多租户解决方案能力。例如如下图：

在一个数据库集群内部，三个APP业务使用不同的节点组和各自单独的CN来做到资源的隔离，完美的实现集群内部的多租户。

通过上面两种解决方案，业务可以根据自己的需要搭建合适的多租户环境，快速部署业务。

TBase 在线弹性扩容：

对于一个分布式系统来说，弹性扩容是一个刚性的诉求，TBase在这一块也不含糊，TBase 老版本时引入shardmap以及shard表，通过shard表TBase可以提供在线线性扩容能力。

在老版本内核中中shard记录按照分配的顺序存储，有可能同样shardid的记录并没有连续存储，扩容业务流程为了完成扩容过程，对底层进行了不少的适配，流程较冗长。

内核在存储层引入了shard聚簇的概念，也就是shardid相同的记录在底层连续存储，大大简化上层业务流程的设计，同时大幅的提升了扩容的效率。

TBase 分区表：

TBase 老版本中我们引入了集群分区表，这个分区表的性能相比社区的分区表，性能在OLTP场景下提升了1-3个数量级，尤其在子表数量众多的时候性能提升尤为明显。整体结构如下：

社区的性能对比：

在这个架构中：

Coordinator: 负责纵向分表，不感知表分区(横向分表)的逻辑。

DataNode：负责横向分表，根据分表字段将一张逻辑表划分为多张物理表。

Tbase也具备这个性能优异的内置分区表功能。然而，除此之外还从PG 10.0继承了社区的RANGE和LIST分区，通过新增加的这两个分区类型，业务在建立分区表时有了更丰富的选择。

TBase 的其他新特性：

• Hash索引支持Crash Safe：

PG10在这个版本中正式引入了Hash index的XLOG机制，也就是说我们可以放心的使用Hash索引了，对于等值查询和in等操作，有了一个相比btree更优的选择。

• 表达式高效运算：

PG10中为了支持JIT，把表达式的计算方法从之前的传统执行器换成了展开执行，表达式的执行效率相比之前大大提升。团队专门做过一个比较，我们把典型的表达式运算做了一个JIT DEMO和PG10的内核表达式展开进行了性能比较，发现PG10的测试结果并不比JIT生成的程序性能差。

• 多核扩展性增强：

事务扩展性：PG从9.6开始陆续推出了多个OLTP事务增前特性，包括XLOG并行落盘优化和系统快照机制优化，从我们团队测试的情况来看，从24核的服务器到96核服务器，事务吞吐量可以做到准线性的提升。也就是说在Tbase下，无论是24核的常见服务器，还是更多核的高端服务器，TBase都可以充分的发挥设备的潜力，把资源充分利用起来。

多核并行执行：PG9.6开始引入并行执行框架，到PG10已经可以做到aggregate，hash join，merge，seqscan，bitmap scan等算子的并行优化。

结语：

当然，TBase还具有很多其它特性，在此不一一赘述。正是在这些能力的支撑下，TBase对于海量数据的OLAP分析类操作更是如鱼得水。腾讯云TBase马上要和大家见面了，腾讯云团队的小伙伴们非常欢迎大家的交流和使用。

PS：5月23日-24日，以“焕•启”为主题的2018腾讯“云+未来”峰会将在广州召开。本届“云+未来”峰会将云集国际知名专家学者、商界精英、行业及技术重量嘉宾，带来80多场主题演讲，共话云计算发展与数字化产业未来。报名地址点击这里（https://cloud.tencent.com/developer/summit/2018-guangzhou?fromSource=gwzcw.914482.914482.914482）