腾讯云国产分布式数据库TBase技术分享

作者简介：许中清，十多年数据库从业经历。从事数据库内核开发、数据库产品架构和规划。曾就职于华为，2015年加入腾讯，参与过TBase、CynosDB等数据库产品研发。专注于关系数据库、数据库集群、新型数据库架构等领域。目前担任CynosDB的分布式存储CynosStore负责人。

2019年5月8日-10日，DTCC2019年中国数据库大会上，腾讯云数据库高级工程师许中清，受邀做了主题为《腾讯云新一代分布式数据库TBase》的技术分享，以下为大会现场演讲内容。

一、关于TBase  

1. TBase的总体架构

首先看下TBase的背景和架构，主要是由三个部分组成：

• Coordinator：协调节点（简称CN），对外提供接口，负责数据的分发和查询规划，多个节点位置对等，每个节点都提供相同的数据库视图；在功能上CN上只存储系统的全局元数据，并不存储实际的业务数据。
• Datanode：用于处理存储本节点相关的元数据，每个节点还存储业务数据的分片，简称DN。在功能上，DN节点负责完成执行协调节点分发的执行请求。
• GTM：全局事务管理器(Global transactionmanager.)，主要是做分布式事务，负责管理集群事务信息，同时管理集群的全局对象，比如序列等，例如序列，除此之外GTM上不提供其他的功能。

2. TBase的特性

2.1 TBase的产品特性：

首先是接口友好，完全兼容SQL2003，支持部分的ORACLE语法，方便了业务接入，降低了业务接入的门槛。其次是有完整的分布式事务能力，稍后会仔细介绍。再有就是在金融级数据安全保护方面的能力，以及我们在开源的基础上做的一些优化，最后就是云多租户的能力。

2.2 TBase的架构优点：

• 多活/多主：每个coordinator提供相同的集群视图，可以从任何一个CN进行写入，业务无需感知集群拓扑。
• 读/写扩展：数据被分片存储在了不同的DN，集群的读/写能力，随着集群规模的扩大做而得到提升。
• 集群写一致：业务在一个CN节点发生的写事务会一致性的呈现在其他的CN节点，就像这些事务是本CN节点发生的一样。
• 集群结构透明：数据位于不同的数据库节点中，当查询数据时，不必关心数据位于具体的节点。

二、TBase 分布式事务

1. 分布式事务一致性为什么重要？

对于分布式数据库来说，分布式事务实际上是最核心最难的部分。所有的分布式数据库都会面临一个问题，就是到底能不能给用户，提供一个数据一致性读写功能。影响事务一致性的场景很多，很多分布式场景用2PC来解决分布式事务的问题，但是2PC不能解决其全部问题。

 2.  分布式事务的核心问题：全局时钟、事务状态同步、死锁检查

• 全局时钟

因为集群里有多个节点，每个节点有自己的时钟，我们怎么在集群范围内做到两个事件间先后关系的比较，例如，如何判断事务A在事务B开始之前提交？ 这是分布式事务的一个基础，只有当事件能够比较，才可以去考虑事务的ACID特性。

• 事务状态同步

一个事务在集群里可能在很多节点参与，这个事务的状态最终一定要同步到每一个参与节点中。只要事务有不同状态，又有先后不同提交顺序，就会涉及到一个问题？从整个集群上看，这个事务到底是什么时候提交的？集群范围内看一个事务状态的翻转，必须只能有一个依据

• 死锁检测

多个事务在单个节点间看没有死锁，在多个节点之间的死锁是一个问题。跨节点死锁如何发现死锁？

3. Tbase怎么做到全局事务一致性？

通过两个手段：

• 第一：全局时钟。GTS从哪里来？逻辑时钟从零开始内部单向递增且唯一，由GTM维护，定时和服务器硬件计数器对齐；硬件保证时钟源稳定度。
• 第二：对MVCC做了一些分布式的改造。多个GTM节点构成集群，主节点对外提供服务；主备之间通过日志同步时间戳状态，保证GTS核心服务可靠性，提升GTM最大容量。

通过MVCC+GTS，保证事务在提交时，无论是什么状态，都能保证最后的读写是一致的。那么，GTM是否会成为整个系统的瓶颈呢？理论上是，因为每个事物都要冲GTM获取时钟。实际上我们还没有遇到过哪个生产系统达到GTM瓶颈，因为TBase GTM的最高吞吐量，我们测过，可以到1200万，也就是说每秒钟产生1200万个时间戳，对于绝大部分系统来说足够了。根据我们用TPCC测试结果来看，TBase在达到300万tpmc之前，吞吐量基本上是随着节点数增加而线性增长的。

三、TBase 分布式查询 

1. TBase分布式查询原理

如上图，对于一个深度查询，在TBase里面最简单的模型是这样的：首先客户端请求连接到协调节点CN（有可能涉及多个节点需要join），CN生成最优查询计划，并将查询计划分发给所有DN。DN接收CN的查询计划并执行。同时根据执行计划的内容，决定是否需要从其他DN节点获取数据。查询完成后，返回最终结果或者中间结果，CN从所有DN收集结果， 并根据实际查询进行处理，返回给客户端。

2. TBase分布式join

TBase分布式join如上图所示，有两张表TBL_A和TBL_B，具体有两种情况：

第一种，异构join等值条件正好在两个表的分布列上。这是最简单的情况。直接把语句下推到每个DN节点，每个DN节点join完后，在CN上做汇总即可。第二种，join等值条件不是在两个表的分布列上。也就是说两张表在DN1和DN2上也要做匹配。

第二种情况又分为两个场景。第一是其中一个表特别小，这张小表会发给每个参与的节点，然后每个节点用这个全量的小表，去join每个大表的一个分片。这样join完了之后，在CN上合并即可；第二个场景是两张表都很大，这时我们的TBase可以内部提供重分布，所谓重分布是说，对于第一张表的join条件是分布列，第二张表的join条件不是分布列的情况，我们把第二张表的join列f2做hash，hash的方式还是以分布列的方式，把每个节点上对f2的hash都发到所有的节点上，重新hash之后，就能保证每个DN上第二张表分片的数据完整，再进行join，这种场景就会涉及DN和DN之间的传输。

3. TBase并行hashjoin优化

下面讲一下针对开源PG来说，我们做了哪些优化。这个优化首先是并行hashjoin的优化。首先看一下在某节点内部是怎么实现社区并行hashjoin的？如上图，比如有一个外表和一个内表。并行Join的时候会有多个worker，每个worker都把内表全量进行哈希，然后用内表的全量哈希结果，跟外表的部分数据进行匹配。

这个过程的问题在于，如果有10个worker内表也要哈希十次？这实际是没有必要的。我们做了什么优化呢？就是在内表哈希过程中，每个worker负责一部分的哈希，然后把哈希结果进行合并之后，得到一份哈希表存于共享内存当中，然后获取部分外表数据与之匹配。这样每个worker只负责一个哈希，这样就可以避免内表哈希多次。

上图是hashjoin优化的效果，可以看到社区并行比非并行性能提升了22.5%，TBase并行比社区并行性能提升18.4%。

4. TBase并行聚合

我们先看一下什么是社区聚合？社区聚合是对于单节点并行的，用一个Gather算子收集各个DN节点的结果。可优化的方式是把要聚合的表/中间表数据进行分片，分完片后每个worker对应于某一个片进行聚合。第一次聚合完之后（现在只是某一个分片聚合）gather算子会把多个一次聚合的结果，再进行第二次聚合然后得到最终结果。这其中有一个问题是：Gather算子这个地方是没法并行的，这可能是影响性能的一个瓶颈，我们怎么优化呢？

具体优化如下：第一步是一样的，每个分片进行聚合。但聚合完之后不是由gather再次聚合，而是把每个分片都广播到所有的worker上面去，每个worker负责对应某一个分片，这就不需要gather即可直接得到最终结果，也就是说我们第二次聚合也能实现并行。

如上图可知聚合优化的结果，社区并行比非并行性能提升29%，TBase并行比社区并行性能提升23%。

当然不仅仅是性能的优化，我们知道社区聚合方式一旦有一个聚合算子，整个执行计划的并行度都会受到影响，因为前面所有的结果都是在一个点聚合的。当我们整体并行计算后，能够解决聚合算子成为并行执行当中的独木桥的问题。效率会提升，整个并行度大幅增加。

四、安全体系 

1. TBase MLS数据安全体系

在我们和客户交流的过程中，多个行业的客户都提到了数据安全的诉求，特别是银行、保险、证券、政企等。基于客户的需求和业界先进的数据库安全解决方案，TBase建设了一套很有特色的数据安全系统， TBase的数据安全系统我们称之为MLS（multiple level security），以三权分立为基础，消除了系统的超级用户权限。

所谓的三权分立，是指把数据库DBA分解为三个相互独立的角色：安全管理员，审计管理员，数据管理员。安全管理员专门用来制定安全/权限规则，审计管理员就是对数据库的操作动态做一个追踪，数据管理员就是对数据库运维的角色。这个三个角色之间相互制约，消除出系统中的上帝权限。从系统角色设计上了解决了数据安全问题。

2. TBase MLS之强制行级安全规则

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

例如某个角色来使用数据库，能看到数据是不一样的。比如董事长能看到所有的数据里，成都分公司的人只能看到一部分。且整个过程对用户不感知，用户并不不知道自己只看到了一部分，以为自己看到的是全量数据，这个整个规则的定义就是安全管理员指定的。

3. TBase MLS之强制行级安全规则

数据加密：简单来说，就是我们把数据存在磁盘里通常都是密文的，就算你拿到整个盘，你也看不到。

透明数据脱敏：

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

4. TBase MLS之审计能力

在与客户交流的过程中，众多客户都提到了数据库审计的诉求。以上是几种审计的方式，有语句审计、对象审计、用户审计等。TBase V2在设计的过程中，结合业界标杆的审计标准设计了自己的审计系统，在内核中实现了审计的核心功能，做到在兼顾高精准的审计粒度的同时还能保证系统的性能。同时针对一些业务中遇到的问题，设计专门的解决方案，做到审计结果的实时通知。整体非常灵活，我们不是僵硬地把数据库所有的操作动作都记录下来，而是根据你的需要，你需要定义什么动作，我就标记什么动作。

同时在事后追溯和实时审计中，TBase提供了完整的审计规则，以及丰富的自定义审计规则来进行支持。通过FGA（细粒度审计），TBase还可以做到数据越权访问的实时告警，实时防止数据越权访问。

以下是提问环节：

Q: 前面讲到，数据在写入的时候直接把权限写进去了，比如机密、公开等权限，这个权限是由什么决定的？

A：是由安全员决定的。安全员相当于是给用户角色的一个标签，比如你用户级别是董事长，如果董事长的安全级别是绝密，那他写入的数据就是绝密的。相当于你写入数据性质，跟你写数据的人的角色是有一定依赖关系的。

Q: 有没有一种情况是，例如他是个BI分析师，级别不是绝密的，但写入的某些数据是绝密的。

A：当然，我们不是说绝密数据必须只能由写密级别用户角色来写。在这种情况下，我们数据库本身其实还有一套授权可见机制来联合使用。强制安全策略除了安全管理员以外，对其他数据库用户是完全透明的，如果一个非绝密级别的用户可以选择写入的数据是绝密的，那就要用户感知到自己的安全级别。