获腾讯研发大奖，国产开源数据库TBase的最佳实践

P腾讯云数据库国产数据库专题线上技术沙龙已圆满结束，本期带来李巍分享的《TBase主要应用场景与最佳实践》直播视频和文字回顾。

关注“腾讯云数据库”公众号，回复“0416李巍”，即可下载直播分享PPT。

1

前言

大家好，我是李巍，腾讯云TBase架构师。今天跟大家分享的主题是：TBase主要应用场景与最佳实践，整体内容分为四部分。

第一部分：关于TBase。前几期TBase直播分享中已有详细介绍，后面我会简单分享下。

第二部分：TBase的选型。今天将主要从应用的角度上来介绍TBase是如何选型的。

第三部分：TBase分布式改造规范。

第四部分：TBase典型业务的介绍，将通过一些业务的介绍给大家整体的认识，看看TBase是否适合自身业务场景。

1

PartⅠ 关于TBase

首先简单介绍一下TBase的发展，TBase主要发展的历程如下图。

TBase是基于开源的PostgreSQL发展而来，最早我们在2009年的时候就引入了社区的PostgreSQL，并做了一些周边的开发，作为腾讯大数据平台（TDW）的一个实时的组件，跟TDW做一个互联互通。在腾讯业务的发展过程中，我们发现单机的瓶颈越来越明显，因此做了一个集群化，业务的增长推动PG的集群化。在2015年，上线了我们的标杆业务——微信支付的商户系统，该业务是偏重于OLTP的场景。接着在2018年我们发布了V2的版本，强化了OLAP的能力并在腾讯云上线，截止目前获得了30余家的外部客户。2019年，我们中标了PICC的核心系统，同年9月份正式上线。

TBase在2019年获得腾讯内部公司级研发奖，TBase是从开源的PG发展而来，我们深刻的感受到开源社区的力量，于是我们将TBase的核心代码对外进行开源，欢迎大家访问：https://github.com/Tencent/TBase。我们也希望借助开源的力量不断的完善和强大TBase。

关于TBase的定位我们总结为五点。

1）高扩展性。兼容PG的一些接口和语法，同时我们提供单机不具备的扩展性。

2）分布式事务。这是TBase区别于一些分库分表插件的一个最基本的特性。

3）高可用性。7×24小时服务，这个是必备的。

4）HTAP。我们是从OLTP演进过来的，同时我们在OLTP的版本里面做了OLAP的演化，当前开源的版本是支持HTAP，由于它需要有一些偏重，所以是70%的OLTP，同时能够支持30%左右的OLAP的能力。

5）易运维。首先是界面化操作，另外还有故障的自愈，以及监控告警的一个完善。

TBase多年来依托内外部业务发展到今天，总的集群数也超过了200个，节点规模也超过了1000个节点，最大的集群单日的请求量突破了10个亿，经受住了很多真实业务的考验。基于此，2019年我们在腾讯云上发布了分布式HTAP数据库 TBase（公有云），欢迎大家通过腾讯云的官网在TBase的页面申请试用，多给我们提一些宝贵的意见。

接下来我们看看数据库开发的一般流程，后面会基于这个流程介绍整个内容。

首先是数据库选型，即业务适合什么样的数据库。这一块要从成本、存储量、并发量和业务增长率去做一个选择。第二个是选的数据库，怎么基于这个数据库来做一些开发规范，这个是非常重要的，做过数据库开发的同学对这个是深有体会的。这里面主要有建表的设计规范， DDL使用规范，还有DML操作规范。第三个是我们制定了一些规范，但是我们不可避免还是会有一些问题，那么怎么去发现这些问题，接下来就此会介绍以下几个内容：

1）锁分析；

2）统计信息；

3）两阶段提交，第3点是因为分布式环境下跨节点的情况，它需要有一个两阶段协议的保证；

4）第四个是业务的优化。

1

PartⅡ TBase选型

首先，我们看一下TBase选型。TBase选型这块儿，我们更多是跟单机的PG做一个对比。

因为TBase集群化之后，它会带来一些成本，首先硬件成本；另外是运维的难度；还有其他功能上的一些问题，比如序列的支持，死锁的问题，两阶段出现的频率等，另外，开发规范会更严格一些。

相反的，集群化带来最大的提升就是扩展性。从OLTP的这个场景来看，我们解决了单机计算能力的不足。这里要提一下，它解决的不是绝对时延，TBase集群在小数据量的写入查询这一块，单个语句的时延可能会比单机差一些。但是TBase多读多写的架构决定它的吞吐量是比单机要更高的。

第二块，OLAP是很好理解，解决单机存储能力的不足，同时在比较大的数据量计算的时，单机时延会比较长，这一块是集群的一个优势所在。在做数据库选型时，我们要综合考虑成本和性能的需求，同时考虑维护的成本是不是可以接受，或者对业务的限制是不是能接受，比如说集群环境下，序列的维护开销是相对比较大的，你会发现如果你的表有序列，其实它的写入能力不是特别好。单机PG到TBase迁移方面我们是有比较成熟的方案能够做一个平滑的迁移。因此，建议在选型层面，单机能够支撑的话，我们尽量优先使用单机来支撑你的业务。后期如果你有集群的需求，你可以做一个很平滑的迁移。

在选型上，我做了一个总结。

第一个：数据量。我们给了参考值，如果你是交易类的业务，数据量大于一个T，或者是分析的业务数据量大于5个T，我们建议你一开始就选择TBase集群来做你的业务数据库的选型。腾讯内部的业务案例如邮箱数据系统和互娱的游戏的分析数据，数据量是比较大的，直接使用的是TBase的集群。

第二个：并发能力。如果你并发连接量需要2000个以上，或者说你峰值请求超过100万每秒，这一块单机肯定是顶不住的，你需要用集群来支撑。比如腾讯内部统一调度系统，以及大数据平台的元数据库这一块，因为它的任务量，查询量非常大，所以它就从单机迁移到TBase集群。

第三个：扩展能力。替代业务原有需要分库分表的场景。

第四个：HTAP的能力。即需要一站式解决OLTP处理能力的同时，又兼顾一定的OLAP的能力，跟我们之前对TBase的定位比较像。

第五个：分布式事务。这个主要的案例是外部的一些传统的业务，因为它对事务的要求其实是比较高的，所以分库分表的系统其实不是特别好支撑，需要用TBase来支撑。

1

PartⅢ TBase分布式改造规范

接下来将介绍TBase分布式改造的规范，分布式改造规范主要有五个点。

第一个：表设计。这个是决定你的数据如何分布，它是后续优化的一个基础。因为你的数据其实是打散到多个节点里面去的，如果你后面表设计得不好的话，频繁的多个节点进行数据交换，性能就不会好。

第二个：索引设计。很重要，这里类似单机PG。

第三个：DDL使用规范。因为DDL比较容易导致分布式锁的，同时，如果在故障的场景下，它会导致一些两阶段提交的事务的残留，我们就需要有一些规范去约束它，让这些问题出现的概率变低

第四个：DML。主要是查询是否跨节点对性能有较大影响。

第五个：避免长事务。它对任何数据库都会有一个比较大的伤害。

首先我们看TBase的表设计。TBase表从大类上分其实是两种表，一种是shard表，第二类表是复制表，就是传统理解的广播表，每个节点都有全量数据。shard表这一块我们分三种，普通表、分区表和冷热分区表。

我们怎么基于自己的业务来选择合适的表类型呢？先简单介绍一下TBase表的一个概念，首先看shard普通表，也就是我们现在TBase里面最常用的一种表，我们看这个语法是distribute by shard，是基于f1做数据分布。

这里面提一个存储组的概念，在后面的冷热分区表里面会利用到这个概念。我们看一下普通的shard表是怎么分布的。假设我有一张表是基于f1列做分布key的一个shard表，那么它的数据是怎么分布的呢。

f1等于1和2的数据，它都在节点1上。f1等于3的数据是分布在节点2上。如果你查询f1等于3的数据，那么它只会把查询推到DN2上，DN1上是不参与计算的，这个是shard普通表的一个概念，以及数据分布的一个特点。

接着看我们shard分区表，PG单机也是支持分区表的，而TBase开发了内置的分区，可以让用户更方便使用。

这个语法是用F2做分区键，我们创建了一个基于月分区的shard表。我们看一下它的数据是怎么分布的，基于前面那个例子，还是两个节点。

F1的1的数据，它基于时间，已经变成不同的子表了，但是它都在DN1这个节点上。这个好处就是说如果你的查询带有时间的话，它很好的利用数据库分区剪枝的特性，它只查询其中的某一个分区，这样就减少了查询的数据量，提升的性能。

关于冷热分区表，我先介绍一下它的背景。我们接入的微信支付的商户系统，查询中90%以上的数据都是近一个月内的数据。但是因为一些监管的要求，它需要保存全量的数据，如果你把全量的数据都保存在好的设备的话，它的成本是比较高的。因此，我们考虑到是不是可以对数据分级存储，就是我把数据分成冷的数据和热的数据，热数据使用存储比较好的，昂贵一些的设备来存。

冷数据性能要求低一些的，可以使用成本会更低一些的设备来存储。系统会屏蔽设备的差异，这样可以很好的兼顾你的查询的性能，成本的节省。TBase现在做冷热分区表的特性就是支持这个场景。如果你也遇到了这个场景，就适合用冷热分区表。

冷热分区表是一个什么概念呢，前面提到，TBase支持多个节点group的，我们这个例子就是两个group，一个是热的group，一个是冷的group。我们热的数据就放在热的group里面，用好的存储设备。冷的数据就放在冷的group里面，用的相对廉价一些的设备。我们有一个全局的冷热路由，这里举个例子，如图 2019年1月1号之前的冷数据就在这个group里面，2019年1月1号以后的数据在这个group里面。我们的建表语法如下。

它跟普通的shard分区表的建表语法基本是一样的，只是在to group这里指定了两个group，default group就是热的group，cold group就是冷的group。通过冷热路由配置，可以很好的定位到数据所在的group，这样的话就是对外屏蔽了冷热设备的一个差异。我们看一下它的数据分布，可以看一下这个存储组，是有两个存储组，还是基于之前的情况，一个default  group是热的group，cold  group是冷的group这一块。我们可以看一下f1的1的数据，其实它分布了两个节点，可以看到DN1，它存储的是2019年1月1号之后的数据，是在default  group里面。2019年1月之前的就是在另外一个冷的group节点当中。   

接下来我们看一下shard表的设计规范。之前在讲解shard表的概念和分布特性的时候已经大致介绍了一下，这里做一个总结。

分布key选择的话，目前是一个字段，我们尽量选择主键来做分布key。如果是复合的主键，就选择重复率低的字段来做分布key。这里的原则是分布key一定要让数据尽可能的分散，这样才能发挥集群化的能力。另外分布key有一些约束，简单的提一点，分布key现在是不支持更改的，这是一个约束。

shard分区表这一块我们该怎么去做。

刚才也提到，你有明确的分区字段，比如说时间，我们建议你一开始在建表的时候就把它建成shard分区表，这样你后面查询的时候带上时间去做查询的时候，会比较好的利用分区的一个特性来提升你的查询能力。分区表这里我们总结一下：它的优势是表大小可以得到有效的控制，索引的高度比较低。第二个是它的更新性能会比较好。但是它也有一些开销，就是全表扫描，还有DDL的开销。如果你的查询没有分区的，基本上都是全表扫的话，我觉得里面用普通的shard表就OK了。

冷热分区表前面有提，适用场景是历史数据查询比较少，占用空间比较大，这个使用场景是相对比较窄一些的。

接下来我们看一下复制表。复制表其实用的不算特别多，也比较好理解，就是我所有的DN数据节点都有全量的数据。

复制表的用处就是，如果你有经常参与JOIN的小数据量表，就是维度表或者字典表比较适合用作复制表。它的前提是数据量要相对比较小，同时更新比较少。如果你更新比较频繁，这样的话其实不适合用复制表，因为它更新需要所有的节点都去参与，它会产生一些锁的问题，会给你的定位问题带来一些烦恼。

我们从使用频率由低到高来做一个总结。

经常要做JOIN的小的字典表或者维度表，我们会建议用复制表。shard分区表是你一般查询带时间过滤，或者其他的条件过滤的话，我们建议使用shard分区表。shard普通表要注意一点是分布key的选择是至关重要的。

接下来我们看一下，我们基于不同的表来怎么进行一个高效的查询。

我们这里举一个shard分区表的例子，基于f1做shard分布列，基于f2做分区列。我们看一下单表查询，我们建议尽量查询条件能够带上分布列，还有分区列。

这样达到一个什么效果呢？我们看一下查询计划，如果我们带上分布列，参与计算的只有一个节点，如果带上分区列，参与查询的只有其中的一个分区。参与计算的节点和参与查询的表尽量的少，这样可以充分的提升你的性能。

多表查询这一块，我们的目标是希望用户跟用单机一样去用TBase集群。以一个两表JOIN举例， A表以F1来做分布列，B表也是F1来做分布列。

JOIN的列和分布列是一样的，查询是可以下推的。如果你的业务特点决定你可能做不到这一点，那么我们尽量把维度表创建成复制表，假设这个B表比较小，就把它创建成复制表，那么我们的查询也是可以下推的。第三个DN节点，其实是可以做到数据的交互的，可以做重分布，性能还是会高的。但是我们建议尽量不要出现太多这种场景，因为DN节点交互的网络开销是比较大一些的。

接下来看一下DDL的使用规范这一块。前面也提了，DDL需要拿一把大锁，开销大。

我们举一个简单的例子，给一个表加一列。假如DN2上有一个比较长的事务，对这个表有一个长事务查询一直没有退出，DDL拿不到锁，它就会一直在等待。那么CN协调节点也需要等待。通过协调节点上对这个表的查询都需要等待这把锁。这样的话，会导致因为你一个DDL的语句，导致你后面正常的业务跑不下去。因此，我们也建议一个规范，就是在DDL前做一个超时，让你拿不到锁的时间够短，对后面的业务影响时间变短一些。在某一些极端的业务上，我们做一个DDL的统一入口，牺牲一定的灵活度来规范这个事情，就是把DDL当做升级来做，尽量的避免对正常业务的影响。有一些线上的系统，它的变动其实是比较严格的，所以它比较适合这种情况。

接下来我们看一下DML，我这里举一个例子是并发update。

update在某一些场景的话，是会导致一些分布式锁的。如果你在单机的话，还没有那么明显。我举个例子，一个简单的update，ID=1和ID=2的数据。如果我们通过两个CN，比较巧的情况的下，在第1个时刻，SQL1发到了DN1上，然后他拿了DN1上的一把行锁。第二个SQL，他同时也把这个SQL发到DN1，他会等这把锁释放。在时刻3的时候，CN1上发起的SQL1，他尝试去更新DN2上的锁。在更早的时刻2，SQL2把查询发到DN2，然后他把ID=2的数据更新了，接着他时刻3，CN1上发出的SQL尝试去更新DN2上的ID=2的数据，但是锁没放掉，他就在这儿等。然后在时刻4的话，CN2上发起的SQL尝试去更新ID=1的这个锁，因为它这个SQL1也没有结束。这样的话就会发现这两个SQL在那里互等，这就是节点间有一个死锁的情况。

这个死锁的问题，TBase是有工具来去发现的，但是因为这个工具运行会有一定的开销，因此运行有一些时间间隔，目前默认是20分钟。所以我们尽量避免这个产生。分布式死锁在分布式的环境下比较容易出现，单机上不会有这个问题。我们怎么去规避呢？其实也很简单，就是把SQL拆成两个SQL，你这样去处理的话，因为它只跨一个节点，不会出现死锁的这种情况，比较容易解决这个问题了。我们遵循DML规范，尽量把数据操作局限在一个节点上，同时避免并发的去更新或者删除。

我们有一个死锁检测的工具，举个例子看一下，这是我们QQ邮箱的一个业务，可以看一到同一个时间发起了同样的SQL，然后发送到不同的DN节点上去。我们的锁其实在DN上去拿的， CN3和CN4上发起的两个SQL在不同的节点中出现了一个互等的情况，这样的死锁是很难去发现的。

所以我们开发了一个运维的工具，也就是一个插件，来解掉死锁。同时我们是有一个定时任务来支撑我们分布式死锁的检测，我们当前是20分钟的时间间隔。

因为有20分钟的时延，一旦出现死锁，对业务伤害还是比较大的，因此我们还是要尽量避免分布式死锁的出现。万一出现的话，我们也有一些机制来保证你的死锁能够顺利的被解掉。

接下来我们介绍一下数据库开发中大家最看重的性能问题。性能问题的排查是非常复杂的。

我们总结一下影响性能的因素，比如网络问题，SQL不够优化，系统的负载，数据的倾斜，还有之前提到的锁的问题。这里面我们选取一点来说明，就是统计信息这一块，统计信息是查询计划生成的一个基础，就是统计信息如果不准的话，你的查询计划肯定是会有一些偏差的。

举个例子，我们腾讯地图的一个业务，因为这两个表非常大，基本上都是上TB了，两个上TB的表做关联，这里面一旦查询计划有问题的话，它可能性能会非常的差，这个例子查询超过60秒都没有返回。查询计划中可以看到它参与计算的节点包含了所有的节点，8个节点都参与计算了。

通过查询计划发现这一块是存在一个优化点的，我们通过一些干预获得预期的查询计划， JOIN都是基于分布列，也是基于索引列来做的，这种场景如果有经验的SQL开发同学的话，这个用nestloop join是更快的。因此我们做了一个很简单的参数的干预，我们把hash join给关掉，然后执行，然后发现它只有400个毫秒就返回了。

通过一些参数来干预它的查询计划可以解决部分问题，但更重要的是统计信息，需要去做一个维护。

统计信息维护，我们做了什么呢？DN节点上，它跟单机是一样的，比如说你定期去analyze表，或者通过表来调整参数来快速的去收集统计信息。另外，我们的查询计划是在CN上发起的，CN上的统计信息也是至关重要的。CN是通过一些参数定时的从DN上去获取的。同时在CN节点之间，我们会去定时的同步统计信息。另外，如果你的数据更新比较频繁，或者你经常会有一些空表导成那种全表的情况，那么建议你可以在导完数据后，定时的去触发你的统计信息的一个采集，这样对你后面查询计划的生成都会有很好的一个帮助。

介绍完一些开发优化，我们看一下我们TBase跟周边系统的一个打通。我们跟业务去沟通的时候，他会说我数据怎么导到TBase上呢？这一点上，TBase提供比较好的数据导入的能力。

对于当前腾讯内部的话，其实有很多组件来支持我们的一个数据的高效的导入。对于一些商业的数据库的话，我们是建议用户这边把数据导到中间件上，接着通过一些比较高效的消费程序，把数据消费到TBase里。同时也可以通过一些可视化的工具，直接导到TBase上来。当前如果我们通过一些批量的写入，比如邮箱集群，现在单日的写入量已经超过1TB，也即超过10亿数据实施的一个写入能力。因为我们业务可能会迁一些数据到TBase上来，它需要老的系统也并跑，相当于需要有一个“备胎”存在，那么它需要TBase的数据能够导出能力。

我们是把数据增量的导出到中间件，同时我们有一些比较高效的消费端程序能够消费到你的目标数据库，比如说oracle、MySQL，这些支持都是OK的。你可以用这种方式完成数据的实时同步，支撑你业务系统并跑的需求。

接下来关于高可用的部署给大家呈现一个简单的图示，后续我们还有系列的分享会介绍这一块。

PartⅣ TBase典型业务介绍

接下来我们简单介绍下典型的业务，看一看我们的业务是怎么使用TBase的。

首先是TBase在微信广告业务当中的应用。微信广告我们分为两部分：实时和离线。图示的TDBank是我们一个实时的组件。然后TDW是一个分布式数据仓库，一个离线的组件。TBase数据有离线和实时两块写入，集群和单机都有使用，数据会给用户来做一些查询。这里面有一个比较重要的业务是微信广告主的报表，这一块也是通过TBase来支撑的。这个业务应用场景有一个大的特点，首先它的数据分析的逻辑是比较复杂的，它有比较大的关联还有聚合的操作，而TBase在OLAP的一个查询的能力较强。

第二个是它的更新是比较频繁的，而且量比较大的。实时任务是5分钟更新一个批次，它为什么没有实时的去更新，这里面有几个原因：第一，5分钟基本上就可以满足它的需求；第二，它规避一个问题，熟知PG的都知道PG会有一些数据膨胀的情况，因为都是更新的话，它用了批量的一些删除和批量写入的情况来规避膨胀的影响。

第三点特点是存储量是比较大的，目前用了10对，就是20个TS80A，每个节点大概有3点几T，它的存储量目前应该是20几个T，量是比较大的；另外就是它的指标会经常的变动，因为它的广告这一块有时候会基于地域或者基于行业，或者基于其他的一些维度，会有灵活的迭代，它的表结构会变动比较大。因此，为了满足它高效的写入和表结构的变更，这一块也做了一些优化。

首先是使用copy来优化它的写入速度，就是它在spark实时写入这一块，会把从insert优化成copy，这样的话它其实是有很好的一个效果的：写入237万的数据，34秒就写完了。

另外就是为了解决它的数据经常变更的情况，它采用了hstore存储的格式来灵活处理表结构的变更，虽然带来了一些读写的开销，但是它提升了业务的灵活度。

第二个业务，我简单介绍统一调度系统，这个系统是腾讯的大数据平台的一个组件，有大量的ETL定时任务跑在上面，这块量是非常大的，系统支撑了基本上腾讯所有的业务，包括视频、音乐、微信广告等，服务的总任务现在有700多万，UV也有3万。

所以老的系统遇到一个问题，老的系统用的是MySQL来支撑它的业务，这一块单机已经支撑不了它的业务了，数据量大导致它的前台查询比较慢，任务的实例化这一块出现了一些瓶颈。

因此它升级成统一调度时在数据库这一层，使用了我们TBase。这也让业务可以专注业务逻辑的开发，数据层就是由数据库来做。这一块同时使用读写平面，前端查询，我们用读平面来支撑；写平面支持任务的实例化和任务的生成，前端查询任务实例化互不干扰。另外就是冷热分离的这一块，现在冷数据是HBase来做的，也在逐步的改成TBase的冷热分离的方案，好处是冷数据是对用户透明的，而现在用HBase的方案是需要做一些数据迁移工作的。最终的效果提升是非常明显的，在实例化的平均速度，还有查询的时延这一块优化非常大。

PartV Q＆A

Q：表类型可以修改吗？

A：表类型如果一旦创建的话是不能够修改的，如果你需要改表类型的话，需要先备份数据，然后重建表，然后把表的数据导进去，这个会对业务有一些影响。

Q：TBase有哪些典型的应用场景？

A：第一个是数据量，因为数据量达到一定级别的话，你单机PG或者承载不了的。第二个是你并发能力这一块，刚才也说了，我们内部的大数据的一个调度系统，其实它为什么需要从单机迁到TBase，就是因为它的业务的峰值非常的高。因为我们的任务调度，ETL任务有很大部分都是小时任务，很多任务都是在每个小时的第一分钟或者某一分钟来调度，所以它会导致它的峰值效应非常的明显。它要么不跑，要么就一下子把任务都实例化了，调起来了。这样你会发现你平时系统相对来说没有那么繁忙，到了这个时候就会把他的任务调起来，单机在并发这一块是顶不住的。还有就是HTAP能力这一块，因为很多系统是不希望去做数据的不同的系统的导入导出，所以他希望你的业务能够在一套系统里面，OLTP的需求和OLAP的需求在一套系统里面能够支撑。比如说我们刚才提到一个微信广告主报表的系统，有些广告主可能查单笔的广告的一些效果数据或者一些收入数据，有些可能会查我最近一个月的收益情况或者一个月的效果情况。这种场景用单机来完全支撑的话，要不你TP能力会比较好，要么你AP能力会相对弱一点，要么你AP可能会影响你的TP能力。如果你有HTAP能力的需求的话，用一套系统来一站式的解决你的诉求。场景这一页PPT里面会有一些解释，我们在后面也介绍了一下针对性的业务。

Q :从Oracle迁移到TBase用什么工具比较好？

A：用户如果有一些数据的抽取能力，他可以把数据抽取到kafka或者这些中间件里面，接着只用我们自己的一些消费程序，消费到TBase上来。如果用户没有这种抽取服务的，我们可能会建议用户用一些开源的工具来做一些存量数据的迁移，增量数据的迁移可能会稍微复杂一些。同时我们也会跟一些Oracle的一些日志解析的工具，比如说DSG或者其他类似的产品做一些合作，后续也会有一些DTS的产品来支持Oracle到TBase的一个数据的迁移。

Q：TBase分布键支持几个字段？

A：目前TBase的分布键一般只支持一个字段，除了shard冷热分区表。冷热分区表是支持两个字段，一个是普通的字段，还有一个字段是我们当前限定为一个时间字段。后续会支持多key分布，会支持多个字段，这个工作正在开发。

Q：每个DN建议多大？

A：这个问题我觉得问的挺好的，其实我们建议每个DN的存储量不要太大，我们当前现网上最大的DN是2TB，我们虽然有一些机器，它的存储比较大，比如说TS80A类型的设备，有4块1.8T的NVME的SSD，但是基本上一个节点使用一个1.8T的盘。我们不建议超过2TB这个值，原因是如果你一个节点太大的话， CPU和内存跟你存储的比值如果太悬殊的话，性能也会有一些影响。

Q：TBase单表存储上限是多少？

A：可以理解为单表是没有上限的。单机PG我记得应该也是TB级别的限制，一般情况下你应该是用不到这么大的量的。现在TBase这块，你可以理解成它是单机PG的单表的限制乘以N，因为我们N个DN，我们其实把数据打散到多个数据节点去存储的。所以这个上限肯定是比单机PG要更高，本来单机PG也已经够大了。但是一般情况下我们不建议单表太大，这也是为什么我们要有shard分区表的这一个类型的表存在。如果你的单表数据量太大，我们建议要么拆散，要么就使用分区表。因为如果你的表很大的话，其实你的索引高度会非常高，你的索引对你的查询性能或者写入的性能都是会有影响的。

Q :每表多大适合？

A:建议单个节点不要超过50GB。你有10个节点的话，我们建议单表不超过500个GB，这只是一个建议，具体还是要看你的业务场景，比如在腾讯地图的业务上，它有很多表已经超过1TB了，现在它的模式是8个节点，你可以理解成它的每个节点单表超过100个G了，这个也取决于你的场景。这个没有很绝对的。只是说我们现在TBase有一个能力，如果你单节点的表很大，我们可以通过一些水平扩容的方式，把你的单节点单表的存储降下来，这个单机的PG是做不到这一点的。

Q：HTAP如何互不影响？

A：我们的大数据调度系统的话，我们是做了读写分离的，从我们的理解上来说，你的AP。就是TP其实对数据的实时信息要求是比较高的。但是你AP对你数据实时性要求相对没有那么严格，所以我们TBase是把数据的备机，就是DN节点的备节点，就是重节点开放了它的读能力。我们的主节点主要用来做OLTP。备节点，我们有一个读平面，我们内部叫读写平面，一个写平面，一个读平面。我们备机作为读平面提供你OLAP的一个读操作，现在主要是这样来做一个互不干扰。

Q：TBase支持存储过程吗？

A：支持。像一些高级的特性，比如说存储过程、触发器，还有一些分析函数，或者是说插件，还有游标这些高级的特性， TBase跟单机PG是一样的。我们现在就用了很多的插件，比如说Hstore，而且有一些分区的插件我们都能支持的。我们分区插件就是用存储过程来实现的，现在公司内部分区的操作基本上都是用分区插件来做，因为TBase当前的版本是基于PG10，它的分区相对还是比较弱的，我们用分区插件来做了一些增强。

Q：序列的性能如何？

A：TBase支持序列，但是我们的规范建议尽量不要用序列，因为它需要做一个全局维护，我们是在GTM节点上去维护的，这个开销其实是蛮大的，尤其是在写入这一块。我们是建议尽量用UUID来代替序列。

Q：TBase写入数据性能如何？我之前做过数据写入测试效果不好，每秒写入能力几千条。

A：如果你采用批量写入的话，每秒写应该可以提升两个数量级是没问题的，每秒几十万数据也没问题。因为我们现在有一个集群，单日的请求量有10个亿的集群，这个量是很大的。大家可以去腾讯云的官网申请TBase公有云做一个测试，如果你在性能测试有什么问题，欢迎留言我们。

Q：按时间划分的冷热表热数据会随着时间流逝自动迁移到冷表中吗？时效性如何？

A：我们有一些定时任务做这个事情，比如说微信支付这边，因为我们冷热表一般是月分区表，我们会在跨月的前面几天把它搬到冷的数据里面去，这个是自动做的。时效性如何？考虑到我们搬迁的过程中实际上对业务的影响是比较小的，这个时效性其实对业务的感知不明显。因为搬迁对你不影响，我们只是在切冷热路由的时候会对业务有一些短暂加一个写的锁。因为它没有影响，所以我们可以在后台慢慢的搬，避免对业务的影响。

Q:支持行列混合存储吗？

A：这个我们当前正在开发的V3版本是支持的，目前开源的V2版本是只支持行存。

Q：扩容后老数据如何清理？

A：我们现在扩容的老数据更多的是通过delete+vacuum的方式做数据的清理，因此老数据清理会对业务造成一些影响。后面会有一些更好的方式来做，比如说做一些数据聚簇的方案，来优化扩容的搬迁和扩容的数据清理对系统的一些影响。

Q：数据库和schema以及用户的关系，相对于Oracle多了一层schema概念，怎么理解？

A：我理解schema其实是一个命名空间，一个逻辑的概念。在你的DB和或者你的索引等对象里面加了一层，它多了一层命名的空间，让你在DB里面可以做一些逻辑的隔离。实际上它的数据都是存在同一个目录里面。如果你没有使用schema概念的话，需要多个DB来做这个事情，你就会发现你需要去跨库查询，那么你需要用DBLINK来实现，需要用一个插件来做。

Q :索引膨胀如何解决？

A：若你更新数据或者数据搬迁确实会有索引膨胀，我们建议是重建索引。因为索引重建是可以并行来做的，对业务其实是没有太大的影响，索引建好后把老的索引删掉就OK了。

以上是今天的分享和Q&A的解答，感谢大家的聆听。

TBase是腾讯TEG数据库工作组三大产品之一，是在开源的PostgreSQL基础上研发的企业级分布式HTAP数据库管理系统。通过单一数据库集群同时为客户提供高一致性的分布式数据库服务和高性能的数据仓库服务，形成一套融合完整的企业级解决方案。大家在数据库领域遇到相关问题时，欢迎随时留言我们。

特惠体验云数据库 

↓↓更多惊喜优惠请点这儿~