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分析能力。行级存储的模式下和某知名数据库相比有相当的优势。
通过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算法，得以充分发挥现有硬件的性能。
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 的其他新特性：
MLS安全体系：
针对用户非常关心的数据安全问题， TBase设计了一套完整的数据数据安全体系，用来支持业务的数据安全，防止数据泄漏。
完整分布式处理能力：
分布式数据需要面对两个非常关键的问题，一个是分布式事务的处理，另外一个是分布式查询，TBase在这两块都做了很多的工作，做到完整的分布式事务ACID能力，同时还具备高效的分布式查询能力。
上面的能力会在后续的文章中一一的进行展示。
结语：当然，TBase还具有很多其它特性，在此不一一赘述。正是在这些能力的支撑下，TBase对于海量数据的OLAP分析类操作更是如鱼得水。腾讯云TBase马上要和大家见面了，腾讯云团队的小伙伴们非常欢迎大家的交流和使用。
作者：李跃森，腾讯云资深数据库专家、大数据专家，PostgreSQL社区成员，负责TBase数据的架构设计和技术研发，超过10年的数据库内核设计开发经验，参与并完成多种数据库的架构设计和开发。
原文地址：http://blog.51cto.com/13730087/2114730
