作者简介：jasonys，隶属于腾讯技术工程事业群数据平台部，负责TBase数据的技术研发和架构设计，有超过10年的数据库内核开发设计经验，完成多种数据库的架构设计和开发。
2017年PGXZ改名为TBase，以发布会的方式正式对外进行了发布，经过团队小伙伴们的努力，TBase V1版本到目前在公司外部市场上的客户包括了政务，公安，消防，电信，金融等行业的十几家客户。TBase以其功能强大，运行稳定，和强大的互联网基因得到客户的普遍认可。在和外部客户的接触中，听到了很多赞美的声音，也有不少希望TBase能够解决客户更多痛点的期望。
2017年中TBase团队结合客户的需求和数据库技术的最新发展趋势，经过相当长时间的规划和讨论，在PostgreSQL最新版本V10.0的基础上规划了TBase V2版本，希望能够代表腾讯最新最强的数据库技术，来满足客户的需求，解决客户业务运行中的痛点。
在接下来的8个多月里，数平小伙伴们夜以继日，终于完成TBase V2核心的开发，这个凝结了数平小伙伴们数百个昼夜辛勤工作的版本终于要和大家见面了，很高兴能能在这里给同学们介绍TBase V2的核心概念和架构。
TBase V2核心概念
TBase V2的重要的技术特性和概念，主要包括以下几个方面：
企业级：企业级特性包含以下几个方面：
- 用户友好的事务特性：业务无需关注数据库的事务特性，数据库内核支持完整的分布式事务，保证事务的ACID。
- 用户友好的数据库特性：主键，外键，序列，约束，分区表，存储过程，触发器，子查询等企业级的特性完整支持。
- 用户友好的SQL接口：当前TBase V2能够兼容SQL2003标准，同时还能够兼容常见的ORACLE语法，可以方便ORACLE深度用户的迁移，当前在外部已经有ORACLE迁移的案例。
- 用户友好的分布式查询能力：良好的分布式查询支持能力，数据库内核能够高效的处理分布式JOIN。
NewSQL数据库：相对传统的数据库产品，TBase能够做到高效的在线线性扩容，在集群规模发生变化的时候不会影响到业务的运行。
HTAP能力： Hybrid Transactional/Analytical Processing，即事务和分析混合处理技术，这个技术要求本来资源诉求矛盾的两种业务类型在同一个数据库中完成处理。TBase V2经过专门的设计完美的做到了HTAP，同时具备了高效的OLAP能力和海量的OLTP处理能力。
下面是我们测试的事务测试模型TPCC的benchmark测试结果，系统在每分钟完成的事务量超过310万，更大规模集群的测试还在进行中，从当前的架构设计来看，在硬件允许的情况下，系统的事务吞吐量会随着集群规模准线性提升：
下面这张图展示了TBase在行存储模式下和业界MPP数据仓库标杆在OLAP测试集合TPCH 1Tbenchmark下的对比情况：
通过这张图可以直观的看到TBase的OLAP分析能力，TBase在22个用例中每个用例的耗时都优于我们的竞品，部分用例耗时大幅度的超过对方。
通过HTAP技术，业务可以在单一的TBase集群中同时处理OLTP类交易和OLAP类分析。通过HTAP，可以大幅度的减少业务系统的复杂度，降低运维成本。
高数据安全：
在和客户交流的过程中，多个行业的客户都提到了数据安全的诉求，TBase团队结合客户的需求和业界先进的数据库安全解决方案设计了TBase V2的数据安全体系。这个体系主要包含以下几个方面：
- 三权分立：把数据库系统dba的角色分解为三个相互独立的角色，安全管理员，审计管理员，数据管理员，这个三个角色之间相互制约，消除出系统中的上帝权限，从系统角色设计上了解决了数据安全问题。
- 强制安全规则：结合业界先进的数据库安全解决方案，TBase V2提出了强制安全规则解决方案，通过安全管理员制定的强制安全规则，可也做到行级可见和列级可见，进而限制用户看到的数据，对不同的用户做到权限的行列混合控制，有效的杜绝数据越权查看，保证关键数据的安全性。
- 透明数据脱敏管理：对于金融，安全等对数据安全有特殊要求行业，经常会有数据脱敏的诉求，但是现有的解决方案很多都需要有业务的参与，要求业务深度的参与，有一定的门槛。TBase针对这个痛点进行了专门的设计，做到业务的透明脱敏，业务只需要根据自己的业务规则结合TBase的脱敏语法，设计业务逻辑。TBase内部就可以做到数据的脱敏，同时结合上面提到的强制安全规则，安全管理员可以做到指定数据脱敏的针对用户，最终达到高安全级别的用户看到的是非脱敏的数据，低安全级别的用户看到的是脱敏后的数据。
- 审计能力：在与客户交流的过程中，众多客户都提到了数据库审计的诉求，TBase V2在设计的过程中，结合业界标杆的审计标准设计了自己的审计系统，在内核中实现了审计的核心功能，做到在兼顾高精准的审计粒度的同时还能保证系统的性能。同时针对一些业务中遇到的问题，设计专门的解决方案，做到审计结果的实时通知。
多租户能力：
TBase提供集群级和集群用户级两个级别的多租户能力。通过集群级的多租户能力，可以帮助业务快速的建立一个数据库私有云，帮助客户快速提供基于TBase的DRDS服务。集群级的多租户能力架构如下图：
除此之外，TBase数据库集群内部还提供基于节点组node group的集群内多租户解决方案，做到数据库集群内部的业务和资源隔离，多个业务在Tbase内部相互隔离的运行。下图APP1，APP2，APP3同时在一个数据库集群内部运行，相互之间通过group进行隔离，互不影响。
TBase产品架构
上面总体上介绍了TBase V2的技术特性，第一次接触TBase的同学还是有点不明所以，为了方便小伙伴们的理解后面的内容，这里把TBase整体架构介绍下。V1和V2在整体架构上是类似的:
集群中有三种节点类型，各自承担不同的功能，通过网络连接成为一个系统。这三中节点类型分别是：
- Coordinator：协调节点，对外提供接口，负责数据的分发和查询规划，多个节点位置对等，每个节点都提供相同的数据库试图；在功能上CN上只存储系统的全局元数据，并不存储实际的业务数据。
- Datanode：处理存储本节点相关的元数据，每个节点还存储数据的一个分片。在功能上，DN节点负责完成执行协调节点分发的执行请求。
- GTM:全局事务管理器(Global transactionmanager.)，负责管理集群事务信息，同时管理集群的全局对象，比如序列，除此之外GTM上不提供其他的功能。
通过上面的架构，TBase提供了一个具有友好接口的数据库集群。这个数据库集群架构上具有如下优点：
- 写可扩展 (Write-scalable)：可以部署多个CN，并且同时向这些节点发出写操作。
- 多主节点 (Multi-master )：系统的每个CN节点都可以发起写入操作，并都可以提供统一完整一致的数据库视图；
- 数据自动同步（Synchronous)：对于业务来说，在一个CN节点的写入操作会立刻呈现在其他的CN节点上；
- 数据透明（Transparent）：是指数据虽然存在于不同的DN节点中，业务在通过CN查询数据库时，还是可以像使用普通的数据库一样编写SQL语句，不必关心数据位于具体的节点，TBase数据库内核自动完成SQL的调度执行，并保证事务特性。
TBase V2特性详解
V2 OLAP能力提升：
说到OLAP能力的提升，首先要讲下TBaseV1和V2在处理OLAP类请求时的差异，V1和V2在处理OLAP请求时的差别主要有执行方式和DN节点之间是否相互通信两个方面：
执行方式：V1中执行OLAP类请求时CN下发到DN的是SQL语句，DN负责SQL语句的规划和执行，然后向CN上报结果，CN完成结果的汇总。V2中，CN收集集群的统计信息，对OLAP类的查询规划集群级的分布式查询计划，并下发到各个DN上进行执行，也就是说CN下发的是执行计划，DN只负责执行而已。
DN之间是否交换数据：V1中，DN之间相互没有通信通道，无法进行数据交换。V2版本在DN节点之间建立了高效数据交换通道，可以高效在DN节点之间交换数据。
差异如下图所示：
在V2 OLAP框架的基础上，我们开发了一整套完整高效的多线程数据传输机制，在运行OLAP查询时，这套框架保证数据可以高效的在节点之间完成同步，大幅的提升OLAP处理效率。
在算法层面，基于PG10具备的多核并行执行能力，我们在集群环境下系统性的重新设计了常用的JOIN，AGGRATE算法，得以充分发挥现有硬件的性能，在同样的集群规模下，测试OLAP benchmark TPCH 1T，在行存储模型下，平均性能超过业界标杆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 V2 HTAP处理能力：
在讲TBase的HTAP能力之前，先分析下当前市面上主流分布式数据库架构在HTAP方面的能力，我们这里不讨论诸如Exadata，HANA之类的一体机解决方案。
首先讲下在互联网公司常见的sharding分布式架构：
这种架构通过物理上的分库分表把多个单机数据库实例使用中间件提供统一的数据库访问接口，达到分布式数据库的效果。这种架构在处理简单的SQL请求时具备一定的竞争力，但是对于处理复杂的分布式join和子查询等复杂SQL往往力不从心，因此不太擅长从事HTAP类的业务处理。
第二种架构，经典的MPP架构，典型的产品是PivotalGreenplum，这种架构中只有一个单Master节点，使用主用数据节点提供查询服务，该架构为OLAP而生，因为单Master的问题，系统的处理能力受限于master的处理能力，而且系统锁最小粒度为表级，直接影响到事务的处理能力，这种架构只适合用来处理OLAP类业务，不适合处理OLTP类业务。
上面讲了sharenothing的架构，后面分析下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的安全体系分为以下几个层次，首先在系统的角色上进行了分解，把备受诟病的DBA超级权限进行了分解，分为了安全管理员，审计管理员，数据管理员，这个做法业界叫做“三权分立”，如下图：
这个三个角色可以对应到美国的三权分立的政治体制：
安全管理员（立法权）：
• 制定强制安全访问策略。
• 强制安全访问策略由安全员独立完成。
• 系统所有用户都要遵守强制安全访问策略。
审计管理员（司法权）：
• 系统所有操作都被记录，包括安全员，管理员的操作。
• 审计策略由审计管理员单独制定。
• 审计员本身的操作也会强制记录，不可修改。
数据管理员（行政权）：
• 具备自主访问控制权。
• 不可干预审计员和安全员的动作
通过这三个角色的划分，从根本上杜绝了系统的安全死角，安全管理员负责整体安全规则的制定，通过这种方式来约束系统中的所有角色。审计管理员负责指定审计规则，审计系统中包括审计管理员在内的所有角色，做到系统所有操作的可追溯。而数据管理员则负责数据库的日常运维。三者之间相互约束，相互监督。
TBase安全架构之—强制访问规则：
强制访问规则听起来有点抽象，我这里拿一个具体的例子来讲，一个公司的员工信息如下表：
对于公司的董事长来说，我们给他的安全规则是看到系统的所有的数据，因此他看到这张表里面的数据是这样的，完整的数据而且没有经过处理：
安全规则规定工程部总经理只能看到工程部自己员工的相关数据，因为薪酬和员工私人信息是高安全级别数据限制对他开放，因此他看到的这张表的数据是这样的：
对于工程部员工张三来说，系统通过访问规则限制他只能看到自己的数据，因此他在系统中通过select看到的数据是这个样子：
这里张三可以看到自己的薪酬数据。
TBase提供了完整的安全规则SQL命令来让安全管理员可以很方便的定义安全规则，通过这些安全规则就可以做到数据行列混合访问控制。
TBase安全架构之—透明数据加密和脱敏：
经常有客户会给我们提安全相关的问题，一个问题是：数据业务托管在某个服务商那里，表中的有些列的内容不想让服务商看到，但是服务商为了运维他们的业务又需要知道表结构，问我们有没有很好的技术手段来解决这个问题。另外一个常见的问题是：如果数据库文件被人拖走了，我们如何保证数据的安全性。针对这一类的需求我们设计了TBase的透明加密和脱敏系统，来全放方位保证用户数据的安全性。
针对这些数据安全类的需求，TBase设计了数据的透明加密和透明脱敏特性。透明加密和透明脱敏功能可以单独使用也可以组合使用。区别和原理如下：
透明加密：主要是预防数据文件泄漏后发生的数据泄漏，因此我们在存储层的文件中存储的是加密后的数据，对与上层业务访问来说，业务读取到的都是明文。
透明脱敏：透明脱敏是强制访问规则的一部分，因此脱敏规则是针对具体的数据库角色建立的。对于授权用户来说，可以正常的读写数据库表中的数据，对于非授权用户来说，他只能看到数据脱敏后的结果，这样可以有效的防止非授权被非法读取。
透明加密+透明脱敏：这种方式下，在磁盘上存储的是密文，可以防止数据文件泄漏后用户数据的泄漏，同时还通过强制安全规则来避免非授权的数据访问，做到存储层和业务层两个纬度的数据安全。
这里还拿上面的数据做为例子，假如透明脱敏安全规则约束薪酬，个人信息，家庭住址，年龄四个列对DBA进行数据透明脱敏，那么DBA在查询这张表时，看到的数据就是这样的：
从图中可以看到，脱敏后的数据都被显示成了系统默认值，DBA是不能看到这个列的值，而且也没有其他的办法来试探这个列的真实值。
TBase安全架构之—审计：
结合业界先进的解决方案和做法，我们把TBase的审计分为以下几种：
- SQL审计：对特定的SQL语句进行审计，与具体的对象没有关系。只针对具体的SQL类型。语法格式如下：
sql_statement_shortcut即SQL审计的内容，这里重点介绍下，ALL包含了下表的审计项，基本上是DDL statements。下面是审计statement列表。
- 对象审计，审计指定对象的指定SQL类型，也就是在指定对象上细化上面的审计情况。动作如下图。
TBase的审计采用独特的设计架构，审计运行的过程中，对系统的性能影响很小。细粒度审计，这种审计方式比较灵活，可以对数据设置过滤条件，如果满足条件的数据被访问了就会触发审计动作，审计动作可以是系统的标准动作，也可以是用户的自定义动作，比如告警，发短信，发邮件之类的。
TBase的审计采用独特的设计架构，审计运行的过程中，对系统的性能影响很小。
TBase V2d多租户能力
TBase作为一个企业级的分布式数据库，还提供了企业常常用到的多租户能力，让客户可以在一个数据库环境运行多个业务，TBase负责多个租户之间的隔离，做到业务之间的相互无影响。
TBase的多租户整体架构如下：
TBase的多租户管理分为三个层级，最底层是资源管理层，这一层管理基础的物理机，并对物力进行资源切片和池化以及各个分片之间的隔离，同时还负责对上层的资源分配和释放。
第二层是租户管理层，这一层负责租户内部的权限管理，每个租户内部都有一个完整的三权分立体系，每个租户可以对应多个项目，每个项目对应一个集群，集群对物理资源的存放位置不感知。每个租户只可以看到自己相关的项目和集群。
最上面一层是系统管理，这一层负责租户和集群的创建，并管理整个平台的资源分配和释放，这一层可以看到整个平台的租户和集群，以及物理机的状态信息。
在系统提供的集群级多租户外，在单个TBase集群内部，还提供了基于节点组的集群内部多租户解决方案能力。例如如下图：
在一个数据库集群内部，三个APP业务使用不同的节点组和各自单独的CN来做到资源的隔离，完美的实现集群内部的多租户。
通过上面两种解决方案，业务可以根据自己的需要搭建合适的多租户环境，快速部署业务。
TBase V2 在线弹性扩容：
对于一个分布式系统来说，弹性扩容是一个刚性的诉求，TBase在这一块也不含糊，TBase V1时引入shardmap以及shard表，通过shard表TBase可以提供在线线性扩容能力。
在V1内核中中shard记录按照分配的顺序存储，有可能同样shardid的记录并没有连续存储，扩容业务流程为了完成扩容过程，对底层进行了不少的适配，流程较冗长。
V2内核在存储层引入了shard聚簇的概念，也就是shardid相同的记录在底层连续存储，大大简化上层业务流程的设计，同时大幅的提升了扩容的效率。
TBase V2 分区表：
TBaseV1中我们引入了集群分区表，这个分区表的性能相比社区的分区表，性能在OLTP场景下提升了1-3个数量级，尤其在子表数量众多的时候性能提升尤为明显。整体结构如下：
社区的性能对比：
在这个架构中：
Coordinator: 负责纵向分表，不感知表分区(横向分表)的逻辑。
DataNode：负责横向分表，根据分表字段将一张逻辑表划分为多张物理表。
TBaseV2也具备这个性能优异的内置分区表功能。然而，除此之外V2还从PG 10.0继承了社区的RANGE和LIST分区，通过新增加的这两个分区类型，业务在建立分区表时有了更丰富的选择。
TBase V2 的其他新特性：
- Hash索引支持Crash Safe：
PG10在这个版本中正式引入了Hashindex的XLOG机制，也就是说我们可以放心的使用Hash索引了，对于等值查询和IN等操作，有了一个相比btree更优的选择。
- 表达式高效运算：
PG10中为了支持JIT，把表达式的计算方法从之前的传统执行器换成了展开执行，表达式的执行效率相比之前大大提升。团队专门做过一个比较，我们把典型的表达式运算做了一个JIT DEMO和PG10的内核表达式展开进行了性能比较，发现PG10的测试结果并不比JIT生成的程序性能差。
- 多核扩展性增强：
事务扩展性：PG从9.6开始陆续推出了多个OLTP事务增前特性，包括XLOG并行落盘优化和系统快照机制优化，从我们团队测试的情况来看，从24核的服务器到96核服务器，事务吞吐量可以做到准线性的提升。也就是说在TBase V2下，无论是24核的常见服务器，还是更多核的高端服务器，TBase都可以充分的发挥设备的潜力，把资源充分利用起来。
多核并行执行：PG9.6开始引入并行执行框架，到PG10已经可以做到aggregate，hash join，merge，seqscan，bitmap scan等算子的并行优化。在这些并行能力的支撑下，TBase V2对于海量数据的OLAP分析类操作更是如鱼得水。
