1、腾讯TBase在保险行业的应用实践李巍 腾讯数据平台部高级工程师|TBase开源github地址：https:/ 保险业务现状与诉求 保险核心系统TBase分布式改造最佳实践|保险业务的特点业务种类多、业务流程长业务种类多、业务流程长增长迅猛，增长迅猛，尤其是互联网相关的业务数据分散，数据分散，无法充分发挥数据的价值无法自主可控无法自主可控，采用国外的商用数据库保险业务特点|保险业务对数据库的诉求车险，财险等，并发要求不高但是业务场景复杂：多表join，交易流程长（操作数据表多大百张）更新频率较低复杂查询效率高业务逻辑简单但并发大增长快，而且有突发增长周边配置系统多系统就近接入，提供吞吐量读多

2、写少单机能力提供传统业务互联网业务配置信息库通用诉求：分布式集群化，为业务转型提供基础，充分挖掘数据的价值基本诉求业务特点|为何选用TBaseWhy TBase|TBase定位TBase是腾讯基于PG研发的新一代分布式NewSQL国产数据库，具备业界领先的HTAP能力，在提供NewSQL便利性的同时还能完整支持事务并保持SQL兼容性。无共享MPP完整分布式事务兼容SQL2003高度安全|TBase发展历程2011年引入PostgreSQL作为腾讯大数据平台的实时组件2015年业务增长推动单机PG集群化，上线标杆业务微信支付商户系统2018年发布V2版本，强化OLAP能力，获取30余家外部客户2

3、019年TBase中标大型保险核心系统，9月正式上线成为保险行业第一个分布式国产数据库01020304腾讯公司级研发奖开源回馈|TBase应用情况200TB1000+最大单集群节点总数最大集群节点数20010亿最大单日请求量200总实例数腾讯地图TBase 标杆客户分布式HTAP数据库 TBase（公有云）稳定、安全、高性能的分布式数据库，满足您海量 HTAP 场景https:/ DataLocal catalogDatanode1Global catalogCoordinatorTransation InfoGlobal objectGTM-MTransation InfoGlobal ob

4、jectGTM-SGlobal catalogCoordinatorGlobal catalogCoordinatorLocal DataLocal catalogDatanode2Local DataLocal catalogDatanode3Local DataLocal catalogDatanode4Data Forward Bus 集群数据交互总线Coordinator(协调节点CN)业务访问入口，每个节点对等，对外提供一致视图Datanode(数据节点DN)业务数据存储节点GTM(事务管理器)全局事务管理器，协调集群集群事务，并管理全局对象指标监控运维管理实时告警安全审计数据治理统

5、一资源管理平台分布式锁分析保险核心系统分布式改造最佳实践|数据库开发的一般流程开发规范问题发现业务优化表设计规范DDL使用规范DML操作规范锁分析统计信息两阶段提交分区表、索引避免跨节点查询业务逻辑优化异常数据消除数据库选型成本存储量并发量业务增长率|数据库选型-PG单机 or TBase集群考量项TBasePG单机硬件成本较高（一定规模才能发挥作用）低运维难度高一般扩展性高一般最大存储支撑百TB1TB（性能考虑，不建议过大）并发能力万级别一般低于100序列支持能力对系统开销影响大，使用需要慎重随意使用死锁消除能力节点内自动，节点间需要借助工具具备两阶段提交出现频率较容易出现，需要多重机制保护

6、一致性极少出现统计信息维护难，如何快、准容易开发规范遵循严格较为宽松集群的最大提升-扩展性OLTP场景：解决计算能力的不足、而非时延（集群在小数据量的写入、查询，单个语句时延可能会大于单机）OLAP场景：解决存储能力不足，大数据量下的时延以及吞吐量|TBase应用场景总结数据量交易数据量大于1T以上，或者分析数据量大于5T以上 并发能力并发连接数量达到2000以上，业务要求每秒峰值100万笔业务交易在线水平扩展 替代业务原有需要分库分表的场景HTAP能力 具备高并发的OLTP处理能力的同时，兼顾相当量级的OLAP分析能力，支持一站式解决业务对数据库的诉求。分布式事务 将事务机制融入到数据库内，

7、解决分库分表模式的痛点|分布式改造规范分布式改造规范表设计索引设计DDL使用规范DML避免长事务决定数据如何分布，优化基础很重要，这里类似单机PG易导致分布式锁、两阶段提交的残留查询是否跨节点对性能有较大影响长事务对任何数据库系统都是一个伤害！|TBase表设计表设计 1.shard表-普通表2 shard表-分区表3 shard表-冷热分区表4 复制表5 如何选用合适的表类型数据表的选择|shard表-普通表字段名类型f1（分布键）intf2varchar(20)DN节点节点f1f2DN11tbaseDN12pgxzDN23postgres记录分布表定义CNDN1DN2数据表-数据分布|sh

8、ard表-分区表CN1DN1DN2数据分布情况DN节点子表f1f2f3DN1子表112019-01-01 00:00:00tbaseDN1子表122019-01-31 23:59:59pgxzDN1子表212019-02-01 00:00:00postgresDN2子表132019-01-01 00:00:00postgresDN2子表232019-02-01 00:00:00postgres|shard表-冷热分区表create table public.t1_cold_hot(f1 int not null,f2 timestamp not null,f3 varchar(20),prim

9、ary key(f1)partition by range(f2)begin(timestamp without time zone 2017-01-01 0:0:0)step(interval 12 month)partitions(4)distribute by shard(f1,f2)to group default_group cold_group;没有指定shard key，默认用主键f1做shard key用f2时间字段进行分区按上述规则分区后，存储在default_group（热）和cold_group（冷）两个存储组中DN1DN2CN1热GROUPDN3DN4冷GROUP全局冷

10、热路由日期参数2019-01-012019-01-01之后数据2019-01-01之前数据|shard表-冷热分区表（续）存储组DN节点子表f1f2f3default_groupDN1子表112019-01-01 00:00:00tbasedefault_groupDN1子表122019-12-31 23:59:59pgxzdefault_groupDN1子表212020-01-01 00:00:00postgresdefault_groupDN2子表132019-01-01 00:00:00postgresdefault_groupDN2子表232020-01-01 00:00:00post

11、grescold_groupDN3子表112017-01-01 00:00:00tbasecold_groupDN3子表122018-01-01 00:00:00pgxzcold_groupDN4子表232018-06-01 00:00:00postgres|复制表DN节点节点f1f2DN1,DN21tbaseDN1,DN22pgxzDN1,DN23postgres记录分布create table public.t1_rep(f1 int not null,f2 varchar(20),primary key(f1)distribute by replication to group defa

12、ult_group;CNDN1DN2指定分布方式|如何选用合适的表类型数据有时间字段，查询一般带时间条件过滤的分区表对应的分布键内容设计时最好带有分区信息shard分区表经常要跨库JOIN的小数据量表可以考虑使用复制表更新频率较低不做常规使用复制表常规使用时采用的分布键（shard key）的选择至关重要shard普通表好处：将join推到每个数据节点计算，没有数据重分布的过程好处：表大小得到控制，索引高度低缺点：多分区查询稍慢，DDL开销大缺点：数据更改开销大默认建表类型分布key一定要让数据尽可能分散|如何高效的进行查询create table public.t1_pt_select(f1

13、 int not null,f2 timestamp not null,f3 varchar(20),primary key(f1)partition by range(f2)begin(timestamp without time zone 2019-01-01 0:0:0)step(interval 1 month)partitions(2)distribute by shard(f1)to group default_group;shard+分区表带上分区以及shard key，减少参与节点以及分区|如何高效的进行查询postgres=#explain select*from t1_pt

14、_select where f1=1 and f2=2019-01-01 and f2 Index Scan using t1_pt_select_pkey_part_0 on t1_pt_select_part_0 (cost=0.15.4.17 rows=1 width=70)Index Cond:(f1=1)Filter:(f2=2019-01-01 00:00:00:timestamp without time zone)AND(f2 2019-02-01 00:00:00:timestamp without time zone)|DDL语句使用规范DDL统一入口统一入口2超时配置超时

15、配置+重试逻辑重试逻辑1CNDN1DN2alter table box_base add column base_type integer default 01.DDL权限集中化2.牺牲一定的灵活度|DML语句使用规范-分布式死锁产生CN1CN2DN1(id=1)DN2(id=2)时刻1 1时刻2 2时刻3 3时刻4 4SQL：update test set name=tencentwhere id=1 or id=2流程分析：1.时刻1，CN1上发起的SQL拿到DN1上id=1的行锁，并更新了数据2.时刻2，CN2上发起的SQL拿到了DN2上id=2的行锁并更新了数据3.时刻3，CN1上发起

16、的SQL尝试更新DN2上id=2的数据，但是拿不到锁，必须等待4.时刻4，CN2上发起的SQL尝试更新DN1上id=1的数据，但是拿不到锁，必须等待.5.两个session出现互等，跨节点死锁出现SQL commondSQL commond不恰当的DML使用会导致一个问题：分布式死锁|DML语句使用规范-规避死锁CN1CN2DN1(id=1)DN2(id=2)SQL1SQL1SQL2SQL2SQL：update test set name=tencentwhere id=1 or id=2一拆二即可解决SQL1：update test set name=tencentwhere id=1SQL

17、2：update test set name=tencentwhere id=2SQL commondSQL commond规范：1.尽量将数据操作限定在某一个数据节点2.避免大批数据的并发更新或者删除分布式锁分析-跨节点锁的产生|问题发现-消除分布式死锁分布式锁分析-跨节点锁的产生|问题发现-性能问题 你们怎么集群还不如单机跑得快，性能这么差？网络问题，慢，丢包SQL不够优化，执行慢统计信息不正确导致选用了不够优化的查询计划（例如nestloop join/hash join等）建表指定的数据分布不合理，没有利用节点间并行的优势索引不够高效系统负载高，需考虑扩容数据存在倾斜强同步主备延迟等锁

18、等待（包括分布式死锁）分布式锁分析-跨节点锁的产生|问题发现-查询计划查询耗时超过60s，被cancel掉，存在很大的优化空间分布式锁分析-跨节点锁的产生|问题发现-查询计划的干预分布式锁分析-跨节点锁的产生|问题发现-统计信息的维护CN1CN2DN1(id=1)DN2(id=2)analyzeDN节点：vacuum analyze同单机PG，可针对业务特点，配置合适的参数特定的表做对应的优化：ALTER TABLE public.foo SET(autovacuum_analyze_scale_factor=0.0);ALTER TABLE public.foo SET(autovacuum

19、_analyze_threshold=1000);CN节点：定时analyze表CN节点间统计信息的同步机制定时任务触发统计信息的采集analyzeanalyze同步|TBase异构数据迁移 Logical_tool通过解析数据WAL日志，将增量数据格式化为JSON格式报文，通过消息中间件实现数据的传输与同步，实现TBase至其他异构数据库的实时同步。该过程无需创建临时表或使用触发器，对数据库本身的性能影响极小。物理格式不一致kafka “no”:“int”,123 “name”:“string”:”tony”“job”:“string”:”hairdresser”Logical_toolK2X|分布式改造效果TBase大集群/PG单机模式，统一技术路线统一技术路线一个大集群、加强数据共享加强数据共享、拓展更多业务使用场景分布式性能提升明显，百G级别的多表join毫秒级出结果国产化软件国产化软件，技术自主可控TBase分布式改造-全方位提升成本节约开发效率数据共享