AntDB 落地某省电信大数据中心项目的性能优化案例分享

本文链接：https://blog.csdn.net/weixin_36098261/article/details/85173011

亚信科技AntDB 落地某省电信大数据中心项目的性能优化案例分享

某省电信大数据中心项目采购了一套亚信科技AntDB 3.1分布式数据库，2018年8月初开始建设，建设周期一个月。9月份投入运行后，至今已稳定运行数月。AntDB主要存储来自该省电信大数据中心的业务数据，因数据量庞大，采用分库分表设计，存在大量按天分区的继承表，单表数据量达到千万级。业务场景以多表关联分组查询的分析型场景为主，部分场景存在多个结果集合并的需求。

AntDB产品简介

亚信科技AntDB是基于postgresql内核开发的一套多模型分布式数据库，支持pg原生语法的同时，可以兼容ORACLE 85%的语法，在业务从ORACLE往AntDB迁移过程中，对业务可以做到平滑迁移。支持在线秒级扩容，集群统一管理和维护等功能。

本文主要结合大数据中心项目的多种业务场景，分享在该项目运行过程中的性能优化案例。

环境介绍

该项目采用share-nothing架构，由10台X86服务器组成，采用4C8D1GTM的组网架构。
GTM/Datanode/Adbmgr通过流复制协议，全部实现一主一从的高可用环境。

操作系统	centos7.4
内存	256GB
磁盘	普通机械盘
AntDB版本	3.1
AntDB架构	4C8D 1主1从

AntDB部署架构图
在这里插入图片描述

场景优化

AntDB在该省电信落地过程中得到快速认可，基本上解决了客户95%的分析场景，性能也超过了客户的预期，但一些比较复杂业务场景没有达到客户的期望，AntDB团队成员积极分析业务场景的SQL，对AntDB的内核以及SQL的写法进行了持续的优化，研发并支持一序列针对性能优化的新功能。

继承表支持并行扫描
支持多种方式的表连接并行
集群计划支持union all
集群计划支持cte+union all组合
支持小表在集群内广播
内核级+SQL级优化方式，满足客户亿级多表关联分组查询，秒级返回结果的需求

最终性能优化明显，最高的性能提升190倍。

在这里插入图片描述

本文将详细介绍案例 1/3/5/7 的优化过程。

场景1案例分享

场景说明

该案例并不针对具体的业务场景，是从数据库层面为90%的业务场景提升10倍性能。

继承表类似于oracle的分区表，在可管理性、高性能等方面，都为应用程序带来极大的优势。在AntDB3.1版本之前，只支持普通表的parallel seq scan。然而，在真实的业务场景里，普通表都会设计为配置类小表或数据量极小的复制表，并行不会带来性能上的优势，甚至会降低执行效率。真实的业务场景，超大表都会设计为继承表。因此，继承表支持parallel seq scan功能，实际上已经是AntDB3.1新版本发布的一种标准的出厂指标。

优化措施

优化前性能瓶颈	优化措施
单进程顺序扫描继承表	多进程并行扫描继承表

从内核层代码改造，支持分布式数据库继承表的parallel seq scan。

执行时间对比

数据量:5千万	单位：s
优化前	8
优化后	0.8
性能提升	10 倍

在这里插入图片描述

场景3案例分享

场景说明

该场景是报表统计类SQL，用于统计某业务在一段时间内每天的新增用户数，并按省/地市分组统计后汇总输出。

效果如下：
在这里插入图片描述

案例分析

该SQL选择Parallel Nested Loop Left Join并行嵌套循环的连接方式，而基表的数据量是1.2 亿，loop的开销非常高。AntDB研发团队在制定该SQL的优化措施时，决定将并行hashjoin纳入AntDB3.1版本中，以替代nestedloop，提升该场景下的性能。

优化措施

优化前性能瓶颈	优化措施
亿级数据量作为基表时，nestedloop开销非常高。	集群计划支持hashjoin，当大表之间进行连接时，优化器选择执行效率更高的hashjoin。

从内核层代码改造，支持分布式数据库 hashjoin并行。

执行时间对比

数据量:2千万 * 6	单位：s
优化前	190
优化后	6
性能提升	30 倍

在这里插入图片描述

场景5案例分享

场景说明

该场景是报表统计类SQL，用于统计多种业务在某一天的新装用户数，按省/地市分组统计，部分业务允许指定条件过滤后汇总输出。

效果如下：
在这里插入图片描述

案例分析

该SQL使用了cte+union all语法，在AntDB3.1版本之前，对该语法的支持还不够全面，因此，在该场景下选择了效率较差的xc的执行计划。
AntDB研发团队在制定该SQL的优化措施时，决定将cte+union all纳入AntDB3.1版本的集群计划中，以替代pgxc的执行计划，来充分利用集群计划的并行优势。

优化措施

优化前性能瓶颈	优化措施
由于集群计划不支持cte+union all语法，优化器只能选择xc的执行计划，导致无法利用集群的parallel seq scan等并行能力。	集群计划支持cte+union all，集群计划选择parallel seq scan+parallel hash join方式，充分利用分布式数据库并行计算的能力。

从内核层代码改造，分布式数据库的集群计划支持 cte+union all。

执行时间对比

数据量:2千万 * 6	单位：s
优化前	150
优化后	3
性能提升	50 倍

在这里插入图片描述

场景7案例分享

场景说明

该场景是报表统计类SQL，用于统计多种业务在某一天的新装用户数，按省/地市分组统计，并指定多种开关类分组条件后汇总输出。

案例分析

在这里插入图片描述
该SQL在进行group by 分组汇聚时，使用了多个维度，且分组字段均选择text数据类型，导致优化器估算出的分组数太多，从而无法利用parallel能力，而选择了seqscan。

分析该SQL，红框内的字段应该是bool数据类型，然而业务在建模时，选择了text数据类型。如果改成bool类型，对优化器在进行估算分组总数、从而确定最优执行计划选择时，大有裨益：

bool类型只有两种结果
char(1)类型不超过256种结果
text类型分组结果无限大

在对这3个字段的表数据进行统计后，的确只有0和1 两种数据。

最终和业务侧确认，将字段类型由text修改为bool后，该SQL执行效率从原254秒将至 1.5秒。

优化措施

优化前性能瓶颈	优化措施
业务侧表结构建模不严谨，没有结合实际情况选择合适的字段类型，导致在该场景下无法选择最优执行计划。	和业务侧确认，修改字段类型。

和业务侧确认，修改表字段类型。