欢迎你们前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~node
做者:jasonys,隶属于腾讯技术工程事业群数据平台部,负责TBase数据的技术研发和架构设计,有超过10年的数据库内核开发设计经验,完成多种数据库的架构设计和开发。
2017年PGXZ更名为TBase,以发布会的方式正式对外进行了发布,通过团队小伙伴们的努力,TBase V1版本到目前在公司外部市场上的客户包括了政务,公安,消防,电信,金融等行业的十几家客户。TBase以其功能强大,运行稳定,和强大的互联网基因获得客户的广泛承认。在和外部客户的接触中,听到了不少赞美的声音,也有很多但愿TBase可以解决客户更多痛点的指望。算法
2017年中TBase团队结合客户的需求和数据库技术的最新发展趋势,通过至关长时间的规划和讨论,在PostgreSQL最新版本V10.0的基础上规划了TBase V2版本,但愿可以表明腾讯最新最强的数据库技术,来知足客户的需求,解决客户业务运行中的痛点。sql
在接下来的8个多月里,数平小伙伴们夜以继日,终于完成TBase V2核心的开发,这个凝结了数平小伙伴们数百个昼夜辛勤工做的版本终于要和你们见面了,很高兴能能在这里给同窗们介绍TBase V2的核心概念和架构。数据库
TBase V2核心概念安全
TBase V2的重要的技术特性和概念,主要包括如下几个方面:服务器
企业级:企业级特性包含如下几个方面:微信
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的数据安全体系。这个体系主要包含如下几个方面:
多租户能力:
TBase提供集群级和集群用户级两个级别的多租户能力。经过集群级的多租户能力,能够帮助业务快速的创建一个数据库私有云,帮助客户快速提供基于TBase的DRDS服务。集群级的多租户能力架构以下图:
除此以外,TBase数据库集群内部还提供基于节点组node group的集群内多租户解决方案,作到数据库集群内部的业务和资源隔离,多个业务在Tbase内部相互隔离的运行。下图APP1,APP2,APP3同时在一个数据库集群内部运行,相互之间经过group进行隔离,互不影响。
TBase产品架构
上面整体上介绍了TBase V2的技术特性,第一次接触TBase的同窗仍是有点不明因此,为了方便小伙伴们的理解后面的内容,这里把TBase总体架构介绍下。V1和V2在总体架构上是相似的:
集群中有三种节点类型,各自承担不一样的功能,经过网络链接成为一个系统。这三中节点类型分别是:
经过上面的架构,TBase提供了一个具备友好接口的数据库集群。这个数据库集群架构上具备以下优势:
TBase V2特性详解
说到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倍。
GTM是TBase集群中负责处理事务信息的模块,它的处理能力直接决定了系统的事务吞吐量。并且GTM是系统中惟一的单点,它的处理上限直接影响到系统处理能力的天花板。
为此咱们对GTM进行了专门的优化和设计。主要集中在如下四个方面:
除此以外咱们还提出了具备专利的分布式事务一致性技术,来保证在全分布式环境下的事务一致性。经过上面的这些优化,TBase单机群的TPCC事务处理能力获得大幅度的提高,并且处理能力会随着集群规模准线性提高。下面是咱们在60台集群规模下测试的tpcc结果,最大吞吐量达到310W每分钟,此时系统DN,CN资源吃紧,可是GTM资源仍有至关多的剩余,所以随着集群规模的增长,系统的吞吐量还能够继续提高。
在讲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的安全体系分为如下几个层次,首先在系统的角色上进行了分解,把备受诟病的DBA超级权限进行了分解,分为了安全管理员,审计管理员,数据管理员,这个作法业界叫作“三权分立”,以下图:
这个三个角色能够对应到美国的三权分立的政治体制:
安全管理员(立法权):
• 制定强制安全访问策略。
• 强制安全访问策略由安全员独立完成。
• 系统全部用户都要遵照强制安全访问策略。
审计管理员(司法权):
• 系统全部操做都被记录,包括安全员,管理员的操做。
• 审计策略由审计管理员单独制定。
• 审计员自己的操做也会强制记录,不可修改。
数据管理员(行政权):
• 具有自主访问控制权。
• 不可干预审计员和安全员的动做
经过这三个角色的划分,从根本上杜绝了系统的安全死角,安全管理员负责总体安全规则的制定,经过这种方式来约束系统中的全部角色。审计管理员负责指定审计规则,审计系统中包括审计管理员在内的全部角色,作到系统全部操做的可追溯。而数据管理员则负责数据库的平常运维。三者之间相互约束,相互监督。
强制访问规则听起来有点抽象,我这里拿一个具体的例子来说,一个公司的员工信息以下表:
对于公司的董事长来讲,咱们给他的安全规则是看到系统的全部的数据,所以他看到这张表里面的数据是这样的,完整的数据并且没有通过处理:
安全规则规定工程部总经理只能看到工程部本身员工的相关数据,由于薪酬和员工私人信息是高安全级别数据限制对他开放,所以他看到的这张表的数据是这样的:
对于工程部员工张三来讲,系统经过访问规则限制他只能看到本身的数据,所以他在系统中经过select看到的数据是这个样子:
这里张三能够看到本身的薪酬数据。
TBase提供了完整的安全规则SQL命令来让安全管理员能够很方便的定义安全规则,经过这些安全规则就能够作到数据行列混合访问控制。
常常有客户会给咱们提安全相关的问题,一个问题是:数据业务托管在某个服务商那里,表中的有些列的内容不想让服务商看到,可是服务商为了运维他们的业务又须要知道表结构,问咱们有没有很好的技术手段来解决这个问题。另一个常见的问题是:若是数据库文件被人拖走了,咱们如何保证数据的安全性。针对这一类的需求咱们设计了TBase的透明加密和脱敏系统,来全放方位保证用户数据的安全性。
针对这些数据安全类的需求,TBase设计了数据的透明加密和透明脱敏特性。透明加密和透明脱敏功能能够单独使用也能够组合使用。区别和原理以下:
透明加密:主要是预防数据文件泄漏后发生的数据泄漏,所以咱们在存储层的文件中存储的是加密后的数据,对与上层业务访问来讲,业务读取到的都是明文。
透明脱敏:透明脱敏是强制访问规则的一部分,所以脱敏规则是针对具体的数据库角色创建的。对于受权用户来讲,能够正常的读写数据库表中的数据,对于非受权用户来讲,他只能看到数据脱敏后的结果,这样能够有效的防止非受权被非法读取。
透明加密+透明脱敏:这种方式下,在磁盘上存储的是密文,能够防止数据文件泄漏后用户数据的泄漏,同时还经过强制安全规则来避免非受权的数据访问,作到存储层和业务层两个纬度的数据安全。
这里还拿上面的数据作为例子,假如透明脱敏安全规则约束薪酬,我的信息,家庭住址,年龄四个列对DBA进行数据透明脱敏,那么DBA在查询这张表时,看到的数据就是这样的:
从图中能够看到,脱敏后的数据都被显示成了系统默认值,DBA是不能看到这个列的值,并且也没有其余的办法来试探这个列的真实值。
结合业界先进的解决方案和作法,咱们把TBase的审计分为如下几种:
sql_statement_shortcut即SQL审计的内容,这里重点介绍下,ALL包含了下表的审计项,基本上是DDL statements。下面是审计statement列表。
TBase的审计采用独特的设计架构,审计运行的过程当中,对系统的性能影响很小。细粒度审计,这种审计方式比较灵活,能够对数据设置过滤条件,若是知足条件的数据被访问了就会触发审计动做,审计动做能够是系统的标准动做,也能够是用户的自定义动做,好比告警,发短信,发邮件之类的。
TBase的审计采用独特的设计架构,审计运行的过程当中,对系统的性能影响很小。
TBase V2d多租户能力
TBase做为一个企业级的分布式数据库,还提供了企业经常用到的多租户能力,让客户能够在一个数据库环境运行多个业务,TBase负责多个租户之间的隔离,作到业务之间的相互无影响。
TBase的多租户总体架构以下:
TBase的多租户管理分为三个层级,最底层是资源管理层,这一层管理基础的物理机,并对物力进行资源切片和池化以及各个分片之间的隔离,同时还负责对上层的资源分配和释放。
第二层是租户管理层,这一层负责租户内部的权限管理,每一个租户内部都有一个完整的三权分立体系,每一个租户能够对应多个项目,每一个项目对应一个集群,集群对物理资源的存放位置不感知。每一个租户只能够看到本身相关的项目和集群。
最上面一层是系统管理,这一层负责租户和集群的建立,并管理整个平台的资源分配和释放,这一层能够看到整个平台的租户和集群,以及物理机的状态信息。
在系统提供的集群级多租户外,在单个TBase集群内部,还提供了基于节点组的集群内部多租户解决方案能力。例如以下图:
在一个数据库集群内部,三个APP业务使用不一样的节点组和各自单独的CN来作到资源的隔离,完美的实现集群内部的多租户。
经过上面两种解决方案,业务能够根据本身的须要搭建合适的多租户环境,快速部署业务。
对于一个分布式系统来讲,弹性扩容是一个刚性的诉求,TBase在这一块也不含糊,TBase V1时引入shardmap以及shard表,经过shard表TBase能够提供在线线性扩容能力。
在V1内核中中shard记录按照分配的顺序存储,有可能一样shardid的记录并无连续存储,扩容业务流程为了完成扩容过程,对底层进行了很多的适配,流程较冗长。
V2内核在存储层引入了shard聚簇的概念,也就是shardid相同的记录在底层连续存储,大大简化上层业务流程的设计,同时大幅的提高了扩容的效率。
TBaseV1中咱们引入了集群分区表,这个分区表的性能相比社区的分区表,性能在OLTP场景下提高了1-3个数量级,尤为在子表数量众多的时候性能提高尤其明显。总体结构以下:
社区的性能对比:
在这个架构中:
Coordinator: 负责纵向分表,不感知表分区(横向分表)的逻辑。
DataNode:负责横向分表,根据分表字段将一张逻辑表划分为多张物理表。
TBaseV2也具有这个性能优异的内置分区表功能。然而,除此以外V2还从PG 10.0继承了社区的RANGE和LIST分区,经过新增长的这两个分区类型,业务在创建分区表时有了更丰富的选择。
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分析类操做更是如鱼得水。
此文已由做者受权腾讯云+社区发布,原文连接:https://cloud.tencent.com/dev...
欢迎你们前往腾讯云+社区或关注云加社区微信公众号(QcloudCommunity),第一时间获取更多海量技术实践干货哦~