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

---

某省电信AntDB3.1项目，2018年8月初开始建设，建设周期一个月。9月份投入运行后，至今已稳定运行数月。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版本之前，对该语法的支持还不够全面，因此，在该场景下选择了效率较差的pgxc的执行计划。 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秒。

优化措施

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

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

执行时间对比

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

总结

在海量数据的分析型场景里，业务SQL结构复杂多变，上述场景也只是冰山一角。在面对更多分析型场景时，AntDB仍需继续努力。

通过该省项目的运行，进一步加强了AntDB在分析型场景下的处理信心。AntDB在服务好OLTP业务的同时，也在不断提升OLAP业务的处理能力。

参考

AntDB QQ群号：496464280

AntDB github链接