导语 | TBase 是腾讯 TEG 数据平台团队在开源 PostgreSQL 的根底上研发的企业级分布式 HTAP 数据库系统，可在同一数据库集群中同时为客户提供强统一高并发的分布式在线事务能力以及高性能的数据在线剖析能力。本文是对腾讯 TBase 专家工程师伍鑫在云+社区沙龙 online 的分享整顿，将为大家带来腾讯云 TBase 在分布式 HTAP 畛域的摸索与实际。
点击视频查看残缺直播回放
一、TBase 分布式数据库介绍
1. TBase 倒退历程
腾讯云从 2009 年便开始在外部的业务上进行尝试，在企业分布式数据库畛域的自研过程是比拟有教训的。过后次要是为了满足一些较小的需要，比方引入 PostgreSQL 作为 TDW 的补充，补救 TDW 小数据分析性能低的有余，解决的需求量也较小。
但业务缓缓的大了后，须要有一个更高效的在线交易事务的解决能力，对数据库要进行一个扩大，所以前面咱们就继续的投入到数据库的开发过程中。
2014 年 TBase 公布的第一个版本开始在腾讯大数据平台外部应用；2015 年 TBase 微信领取商户集群上线，反对着每天超过 6 亿笔的交易；2018 年的时候 V2 版本对事务、查问优化以及企业级性能做了较大加强，缓缓的开始面向一些内部客户；2019 年 TBase 中标了 PICC 团体的外围业务，帮助了他们在国内保险行业比拟当先的外围零碎，并稳固服务了很长的工夫。
思考到 TBase 整体能力的继续倒退，咱们是心愿把 TBase 的能力奉献给开源社区，这样能更多的反对数据库国产化我的项目。于是在 2019 年 11 月，咱们把数据库进行了开源，心愿能助力数字化产业降级。
2. PostgreSQL 数据库简介
TBase 是基于单机 PostgreSQL 自研的一个分布式数据库，除了具备欠缺的关系型数据库能力外，还具备很多企业级的能力。同时加强了分布式事务能力，以及比拟好的反对在线剖析业务，提供一站式的解决方案。
在数据安全上，咱们有着独特之处，包含三权分立的平安体系，数据脱敏、加密的能力。其次在数据多活、多地多核心的灵便配制下面，也提供了比较完善的能力，保障了金融行业在线交易中一些高可用的场景。为金融保险等外围业务国产化打下坚实基础。
PostgreSQL 是一个开源的 RDBMS，开源协定基于 BSB 格调，所以源代码能够更加灵便的供大家批改，也能够在批改的根底上进行商业化。
PostgreSQL 是由图灵奖得主 MichaelStonebraker 主导的一个开源我的项目，如上图所示，它曾经迭代得比拟久了，到当初曾经公布到 12 版本，并且始终在继续的迭代，整体处于一个比拟沉闷的程度。
3. PostgreSQL 发展趋势
PostgreSQL 在近十年开始受到的大家的关注，首先是因为它的内核性能，包含社区的继续沉闷，在过来几年取得了继续的提高。上图是来自 DB-Engines 的统计，依据数据咱们能够看到在去年整体大家都有一些退化和增长不太高的状况下 PostgreSQL 的提高是比拟显著的。
下图中黄色的曲线是 PostgreSQL，咱们能够很直观的看到它发展趋势是比拟良好的。
目前开源的 TBase 版本是基于 PostgreSQL10，咱们也在继续的匹配 PostgreSQL 更多的性能，后续也会回馈到开源社区，心愿和整体的 PostgreSQL 生态有一个良好的联合和互动。
二、开源 TBase 定位及整体架构
1. 开源 TBase 的定位
数据库依照业务场景次要分为：OLAP、OLTP 和 HTAP。
OLAP 的业务特点是数据量较大，个别是 10PB+，对存储老本比拟敏感。它的并发绝对于 OLTP 不会太高，但对简单查问能够提供比拟好的反对。
OLTP 的数据量绝对较小，很多中小型的零碎都不会达到 TB 级的数据量，但对事务的要求和查问申请的要求会比拟高，吞吐达到百万级 TPS 以上。并且 OLTP 对于容灾能力要求较高。
国内的国产化数据库很多会从 OLAP 畛域进行切入，从 OLTP 角度切入会绝对比拟难，目前这一块还是被 IBM 或者 Oracle 垄断的比较严重，咱们心愿尽快在这一块实现国产化。而 TBase 因为在保险行业有比拟长时间的耕耘，在 OLTP 外围业务能力上有比拟强的。
另外一个是 HTAP。在之前大部分的业务部署中，大家会把 TP 和 AP 离开，在两头可能有 ETL 或者流复式的技术将两套零碎进行交互。但更现实的状况是能够在一套零碎中同时实现两种业务类型的反对。
当然这个会比较复杂。首先大家能够看到他们的业务特点差异比拟大，内核畛域的优化方向也是齐全不一样的，或者说技术上差别比拟大。
TBase 推出 HTAP 也是从具体的需要登程，实际上 TBase 是更偏差于 TP，同时兼顾了比拟好的 AP 的解决能力，在一套零碎里尽量做到比拟好的兼容。但如果要做更极致性能的话，还是要对 HTAP 进行隔离，对用户提供一种残缺的服务能力。
TBase 的角度也是依据需要衍生进去的。腾讯云最早是做交易系统，前面缓缓的补充了 AP 的剖析能力。
这块面临的次要的业务场景需要，首先是交易数据可能会大于 1T，剖析能力大于 5T，并发能力要求达到 2000 以上，每秒的交易峰值可能会达到 1000 万。在须要扩大能力的状况下，须要对原有的事务能力、剖析能力，或者数据重散布的影响降到最低。同时在事务层面做到一个齐备的分布式一致性的数据库。
同时 TBase 也进行了很多企业级能力的加强，三权分立的平安保障能力、数据治理能力、冷热数据数据及大小商户数据的拆散等。
后面咱们介绍了 TBase 的倒退过程，在这过程中咱们也心愿能够为开源社区进行一些奉献。
实际上在国内环境中替换外围业务还是比拟难，更多的是从剖析零碎切入，最近几年才开始有零碎切入到外围的交易事务能力上，TBase 也心愿通过开源回馈社区，保障大家能够通过 TBase 的 HTAP 能力来填补一些空白，裁减生态的倒退。
开源后咱们也受到了比拟多的关注和应用，其中还包含欧洲航天局的 Gaia Mission 在用咱们的零碎进行银河系恒星零碎的数据分析，心愿有更多的同学或者敌人退出到 TBase 的开发过程中，也心愿通过本次介绍，不便大家更好的切入到 TBase 开源社区的互动中。
2. TBase 总体构架
一个集群是由这几个局部组成：GTM、Coordinator 和 Datanode。其中 GTM 次要负责全局事务的管控，是提供分布式一致性协定的基石；Coordinator 是用户业务的拜访入口，对用户的申请进行剖析和下发，具体的计算和数据存储则是放到了 Datanode 当中。
三、HTAP 方面能力介绍
方才咱们讲的是 HTAP，上面咱们先讲一下 OLTP，TBase 在这部分的能力是比较突出的。
如果用户须要在事务或者并发交易量上有要求的话，就须要一套比拟好的分布式事务的零碎。具体的需要包含高性能和低成本，在这部分，TBase 相较于传统的 IBM 或者国外更贵的一体机有较大的劣势。
另外一个需要就是可扩大，在节点扩大的状况上来近似线性的扩大事务处理能力。那要如何达成这个指标？
简略介绍一下事务的 MVCC 的解决，单机 PostgreSQL 次要是保护一个以后的沉闷事务列表，它有一个构造叫 Proc array，相当于每一个用户的 session 有新的事务申请的话，会在事物列表里去记录以后沉闷的事务，当须要判断 tuple 的可见性的话，会在沉闷事务列表里拿一个 Snapshot 去跟存储下面的 tuple header 中记录的 XID 信息进行一个比照，去做 MVCC 的访问控制。
如果是扩大到分布式的状况，一个比较简单的形式是须要有一个核心节点。按之前的构架，在 GTM 下面会有一个中心化的沉闷事物列表，来对立的为每一个拜访的申请去调配 Snapshot。
但这个时候就有一个比拟大的问题，核心节点会成为瓶颈，GTM 也会有一些问题，比如说快照的尺寸过大或者占用网络较高。
GTM 如果做一个中心化的节点的话，实际上存在一个单点瓶颈，每一个申请都要保障它拿到 snapshot 的正确性，这就须要对沉闷事务列表进行上锁，这个在高并发状况下锁抵触会很大。咱们是怎么解决这个问题的呢？
这实际上也是业界一个通用的问题。目前咱们看到互联网行业的计划，是从 Google Spanner 的方向衍生进去的。
Google Spanner 是一个寰球分布式数据库，能够在各大洲之间提供一致性的数据库服务能力。它的管制并发技术特点，一是通过 KV 存储基于全局工夫的多版本并发管制，另外一个是它通过应用老本比拟高的 GPS 和寰球统一的服务工夫戳机制来提供一个 TrueTime API，基于实在工夫制作一套提交协定。因为它的整体寰球分布式，导致平均误差会大略在 6 毫秒左右，整体的事务时延是比拟高的。
另外，有较多的零碎会借鉴 Google Spanner 做事务模型，CockRoachDB 也是其中之一。
另外，Percolator 也是 Google 为搜索引擎提供的一个比拟有效率的数据库，应用 KV 存储，基于全局逻辑工夫戳的 MVCC 进行并发管制。它的工夫戳由专门的工夫戳服务提供，分布式事务第一阶段须要对批改记录加锁，提交阶段完结锁定；事务提交工夫复杂度为 O(N)，N 是记录数，导致提交的性能会有影响，当然这样的设计也和零碎需要相干。
上面看一下 TBase 在分布式事务上的能力，这部分咱们也是在后面的根底上做了较大改良。
首先咱们对 GTM 集群做了优化，从原始的全局 XID 改成了调配全局工夫戳 GlobalTimeStamp（GTS），GTS 是枯燥递增的，咱们基于 GTS 设计了一套全新的 MVCC 可见性判断协定，包含 vacuum 等机制。这样的设计能够把提交协定从 GTM 的单点瓶颈下放到每一个节点上，加重压力，同时通过工夫戳日志复制的形式实现 GTM 节点主备高可用。
这种协定下 GTM 只须要去调配全局的 GTS，这样的话单点压力就会被解决得比拟显著。依据咱们的推算，滕叙 TS85 服务器每秒大略能解决 1200 万 TPS，根本能满足所有分布式的压力和用户场景。
咱们方才也提到，在 Percolator 的实现下，须要对 Tuple 上锁并批改记录，这样的话性能是比拟差的。而实际上咱们对提交协定做了一个优化，在对 Tuple Header 的 GTS 写入做了提早解决，事务提交的时候不须要为每一个 Tuple 批改 GTS 信息，而是把 GTS 的信息存储在相应的 GTS Store File 当中，作为事务复原的保障。
当用户第一次扫描数据的时候，会从 GTS Store File 中取到状态，再写入到 Tuple Header 中，之后的扫描就不须要再去遍历状态文件，从而实现减速拜访，做到事务处理的减速。这样在整体上，让数据库在事务层面保障了比拟高效的设计。
对于集中数据分布的分类状况，有以下三种。
第一种状况是复制表。复制表中的每个存储节点都有残缺的数据正本，实用于变动较少的小表，能够减速关联查问。
第二种是 HASH 散布，这是比拟经典的一种形式。简略来讲就是将数据依照散布列进行 hash，把数据打散在各个存储节点中，如果 hash key 抉择不当，则可能造成数据歪斜的状况。
第三种是基于 RANGE 的散布。RANGE 散布会将数据依照分段打散成小的分片，和 hash 相比散布上不会特地严格，对下层的节点弹性有比拟好的反对。但它在计算的时候，绝对 hash 的成果不会特地好。
在整体上，TBase 抉择的是复制表和加强的 hash 散布。
上面介绍一下如何看分布式查问，PushQuery 和 PullData。
最开始晚期的一些零碎可能会抉择更疾速的实现，比如说存储上是分成多个 DN，而后把数据拉取到 CN 进行计算。
这种状况下优缺点都比拟显著，长处是更高效更疾速，毛病是 CN 是一个瓶颈，在网络上压力比拟大。所以咱们更偏向于上图中左边的形式，把有的数据和计算下放到 DN 结点上。
最根本的状况下，心愿所有的计算能够放到 DN 上来进行。DN 在做重散布的时候，须要跟 DN 间有交互的能力，这个在 TBase V2 之后做了比拟多的加强，目前 TBase 能够将计算尽量的扩散到 DN 结点上来进行。
上图介绍的是 SQL Shipping 和 PlanShipping 的区别。
实际上当解决一个 query 或者一个查问打算的时候，会有两种状况。一种是说我间接把 SQL 通过剖析发到 DN 上执行，CN 只负责后果的收集。这样的优化成果会比拟好，因为不须要在多个节点建设分布式一致性的提交协定，另外在计算资源上效率会更高。咱们在 OLTP 畛域的一些优化会采纳这样的形式。
另一种状况是在 OLAP 畛域，更正规的 PLAN 的分布式。在 CN 上对 query 做一个整体的 plan，依照重散布的状况把打算分解成不同的计算分片，扩散到 DN 上进行解决
方才讲到，就是如果能把对 OLTP 推到某单个 DN 上来做的话，成果会比拟好。咱们举个简略的例子。
两张表的散布列是 f1，数据列是 f2，若 query 能够写成散布键的关联状况，并且采纳的是 hash 散布，就能够把 query 推到不同的 DN 上来做。因为不同 DN 间的数据受到散布件的束缚，不须要做穿插计算或者数据的重散布。
第二类是有散布键的等值链接，同时还有某一个散布键的具体固定值。
在这种状况下，CN 能够通过 f1 的值判断具体推到哪个 DN 中去做。
还有一些更简单的查问，比方存在子查问的状况，但形式也是相似的分析方法。
子查问可能会有一个简单状况，如果在多层的子查问中都能够判断进去跟下层有雷同的繁多节点散布状况，query 也能够下发到 DN 中。这种状况下对 OLTP 性能会有比拟好的影响，集群的能力会失去比拟好的优化。
针对比较复杂的 query，可能就须要波及到优化配置的调整。
形式次要分为两种：规定优化（RBO）和代价优化（CBO）。RBO 次要是通过规定来判断查问打算到底符不合乎进行优化，这个是比拟晚期的一些实现办法，因为计算量绝对较小，所以对某些场景比拟高效，但显著的毛病是弹性有余，同时不能用于比较复杂的场景。
实际上更多的这种数据库应用的是 CBO 的形式。简略讲，CBO 会对所有门路的进行动静布局，抉择老本最小的一条作为执行打算。这种形式的长处是有较好的适用性，可能适宜简单场景的优化，性能体现较稳固。毛病是实现简单，须要肯定的前置条件，包含统计信息、代价计算模型构建等。
但这也是不相对的，两者没有谁能够“赢”过对方的说法，更多是须要对二者进行一个联合。TBase 次要是在 CBO 上进行优化，比方在计算一些小表的场景中，不须要进行 redistribution，间接 replication 就能够了。
对于分布式中文 distribution 的一些调整的状况，咱们还是打个简略的比如。两张表，TBL_A 和 TBL_B。
如果 f1 是散布列，散布类等值的状况下会变成 push down，这种状况下能够在 DN 上间接进行计算。
上图两头的状况中，TBL_A 是散布键，TBL_B 是非散布键。在这种状况下，如果 TBL_B 足够小，必须要对 TBL_B 进行重散布，也就是对 TBL_B 进行 replication，这时就会波及到一些代价的估算。而如果 TBL_B 比拟大的话，可能须要对 TBL_B 进行 redistribution。
方才咱们也讲到，TBase 在 OLAP 方面也有比拟强的能力，这部分的优化思路次要是借助了计算的并行。计算的全并行能力次要体现在几个方面。
首先是节点级的并行，因为咱们是分布式的数据库，所以能够有多个节点或者过程进行计算；另外一层是过程级的并行，目前 TBase 没有改成线程模型，所以并行次要体现在过程级模型中，基于 PostgreSQL 过程并行的能力做了一些加强。还有一层是指令集的并行，对指令进行优化，前面也会对这部分进行继续的加强。
那么 Postgres 的查问打算，或者是过程并行的能力是如何实现的呢？最晚期咱们 follow 的是 PG10，并行能力并不是十分强，只提供了根底的框架和局部算子的优化，这是 TBase 过后进行优化的一个点。
在分布式的状况下，很多单机能够进行并行，但在分布式中就不能够进行并行，所以咱们心愿对这些能力进行一些加强，从而保障更大范畴的一个并行能力。
并行计算其实是一种自底向上推演的形式，比如说底层的一个节点能够并行，那么如果递推向上到了某一层不能并行，就能够把上面所有能够并行的中央加一个 Gather Node，把后果从多个过程中进行收集，持续向上进行布局。这也是咱们心愿加强的一个点。
上面咱们介绍一些具体的优化。
晚期 PG 的 HashJoin 在 outer plan 是能够做并行的，但在 inner 构建 hash table 的状况则不能做并行的。
简略来说，hashjoin 能够分为几步。首先是 build hash table，第二步是获取局部 outer plan 数据，计算哈希值，并进行匹配。这里咱们将 inner hash table 构建过程也做了并行化解决，保障 Hashjoin 的左右子树都能够进行并行，并持续向下层节点推到并行化。
另外一种状况是 AGG（Aggregation）。
很多状况下都是一个两阶段的 Agg，须要在 DN 上做一些 partial agg，而后到下层打算分片进一步做 final agg。实际上在这种状况下，两头碰到 redistribute 须要先在 DN 进行数据的整合，而后再去做 final 的 Agg。
在有多层子查问的状况下，每一层都进行计算会导致最初整体的并行计算不会很高。所以咱们在 redistribution 也做了一些并行，也就是在 Partial Agg 的状况下能够依照 hash 散布去发到对应的下层 DN 节点上进行并行。
还有一些数据传输方面的优化。
咱们提到 redistributio 节点能够进行并行能力的加强，而在数据的承受和发送上也须要进行优化晋升。晚期的版本是单条的解决模式，网络的提早会比拟高，性能会不太好，所以咱们在这部分进行了一些优化，从而实现比拟好的并行执行的能力。
四、开源 TBase 企业级能力介绍
实际上 TBase 还做了一些企业级能力的加强，前面也继续的会去做一些开源奉献和优化。
目前开源 Tbase 企业级曾经能够实现多地多核心，或者是多活能力的构建，包含平安、治理、审计的能力，TBase 在平安下面有比拟高的要求，前面也会继续的奉献进去。
还有就是在程度扩大能力上，TBase 能够做到在用户感知比拟小的状况下进行扩容。扩容在大数据量的状况下是一个广泛的痛点，咱们在这方面的能力上也会有一个继续的加强。
此外，TBase 还有自研的剖析表以及冷热数据的拆散，也都是有比拟好的成果，对于用户老本的升高，还有数据分布的灵活性都会有比拟好的晋升。
TBase 在往年 7 月 13 号开源公布了 v2.1.0 版本，咱们也继续的在开源能力上做着建设，包含多活能力的继续加强、维护性的加强，性能平安继续的降级，包含通过一些企业客户发现的问题也都会继续的奉献进去。还包含统计信息加强以及加强对小表重散布的优化，也是心愿大家能够继续关注 TBase，和咱们进行更多的探讨和切磋。
五、Q&A
Q：TBase 的安排有哪些要求？
A：大家能够拜访 TBase 的开源版本，下面有具体的应用办法和基于源码的构建，还有搭建的流程，都有比拟明确的文档。如果大家想尝试的话，能够应用失常的 X86 服务器或者本机的 Linux 服务器就能够做一些简略的搭建，企业级我的项目上大家也能够做一些尝试，放弃沟通。
Q：为什么抉择基于 PostgreSQL 开发呢？
A：实际上大家会面临 MySQL 和 PostgreSQL 两个方向上的抉择，我次要介绍咱们抉择 PostgreSQL 的起因。
一是 PostgreSQL 的协定会更加敌对，在协定的灵活性上会比拟好一些，大家能够随便的对它的代码做改变和残缺公布。
另外它的内核实现上也比拟谨严，有本人的独到之处，继续的也在加强，包含它的迭代速度也是比拟快。咱们晚期始终在跟进，继续的 merge PostgreSQL 的一些 feature，也是随同着 PostgreSQL 的成长，咱们的内核也做了一个比拟疾速的迭代。同时咱们也在理解内核的状况下，做了一些更深刻的调优。
Q：DN 节点的存储集群是基于 Raft 吗？多 Leader 还是单 Leader 呢？
A：目前咱们的 DN 结点没有用到 Raft 协定，是做的主备复制。我晓得有很多新的业务会基于 Raft 的提交协定，或者是用这种复制的协定去做一致性和高可用。但实际上 Raft 的多正本对提交协定还是有一些性能影响的，整体的流程绝对于传统的会有更长的时延，相当于 CAP 原理，C 进步了，A 会有局部影响。
而咱们更偏向于 OLTP 零碎，所以在事务上的要求和时延响应的要求是比拟高的，于是做了这样的抉择。
Q：能具体讲讲分布式事务的实现流程吗？怎么样保障多机之间的分布式事务，两阶段提交吗？
A：当初咱们根本是 follw 两阶段提交。一个是两阶段提交的管制流程、控制协议，另一个是事务隔离的协定。方才次要讲了 MVCC，在提交协定上基本上两阶段提交的增强版。
因为应用了 GTM，导致它和传统的单机模式不太一样，做了一些对立的协调，方才也着重介绍了。这样的一个劣势是加重了 GTM 上的压力，另外在 prepare 阶段会有局部的阻塞状况，但在优化之后影响是十分小的，却能极大的加重 GTM 的压力。
Q：底层的存储是怎么同时满足行存和列存的需要呢？还是依照块 (Tile) 间断存储？
A：咱们开源版本的底层存储次要是行存，前面会在列存和 HTAP 进行继续的加强，进一步晋升 HTAP 的能力。等逐渐稳固之后，会再思考迭代开源版本。
Q：起码须要多少服务器搭建？
A：其实单点搭建也是能够的。一个 DN、一个 CN、一个 GTM 也能够。实际上最好布成两 DN，能够体验更多的分布式搭建。实际上咱们在企业服务的集群上曾经超过了上千个节点，包含解决 GTM 的单点压力上，对集群整体的扩展性有比拟好的晋升，所以从两个节点到多节点都能够去尝试一下。
Q：GTM 的授时，有采纳 batch 或者 pipeline 吗？还有当初 Tbase 反对的从库的读一致性吗？
A：有的。GTM 的授时咱们也做了更多的优化，简略说能够做一些并行的 GTS 的枯燥授时，依据现行的规模或者是咱们对客户场景的预估，在 x86 服务器中大略能够达到 1200 万 QPS 的授时的能力。在加强服务器的状况下，整体的能力是比拟强的，基本上不会在这部分产生瓶颈。
Q：tbase 有什么平安保障机制?
A：从业务角度，咱们讲到了平安隔离，以及有很强的行级平安规定、列级访问控制以及数据加密、脱敏加强，这些都能够偏向于向一个企业级的数据库去利用，当初很多企业级服务的能力也在 TBase 外面，前面咱们会依据状况进行进一步的迭代。