亚信自研分布式数据库AntDB落地某省电信的案例分享
整体介绍
某省电信大数据分析平台，需要对BSS的三户、订单、实例等近10TB级的数据进行快速分析统计，每次分析的数据量最高达到5亿级别，同时需要向其它厂商开放这种实时的数据分析能力，前期这种数据分析是通过大数据平台Hadoop+Hive的框架进行支撑，但这种框架存在几个不足：1）需要hive脚本将BSS的关系型数据导入到大数据平台的文件中2）需要用Hadoop体系非SQL的MapReduce脚本进行统计，在技术实现上不满足数据分析能力的快速开放，在性能上不能实时返回统计分析数据，在“去O”的大趋势下，却又带来了新的难题与挑战。该省电信开始考虑新的数据库Postgres来支撑这种实时分析的场景，同时采用开源的Postgres-XL数据库集群，但在实际落地的过程中出现性能瓶颈，扩展瓶颈。
在今年8月中旬，CTC PaaS团队向客户推荐使用公司的AntDB3.1产品代替开源的Postgres-XL，并于8月底完成8个节点的部署，8个节点部署8主8从，在整个部署过程中，也向客户展现了AntDB一键化Oracle/MySQL数据迁移工具、在线不停机扩容、主从切换的产品核心能力，AntDB上线后，稳定运行至今，解决了前期遇到的所有性能及技术难题，稳定性与性能大幅提升，得到客户的高度认可，客户也承诺将AntDB产品纳入该省电信企业级PaaS平台的组件，将8节点扩展成32节点，将AntDB这样优秀的数据库能力提供给更多的系统进行使用，更好的支撑该省电信IT化建设。
项目实践
部署架构
该项目采用share-nothing架构，由10台X86服务器组成，采用4C8D1GTM的组网架构。
GTM/Datanode/Adbmgr通过流复制协议，全部实现一主一从的高可用环境。
复杂场景优化
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倍 |
案例分析
该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秒。
优化措施
| 优化前性能瓶颈 | 优化措施 |
|---|---|
| 业务侧表结构建模不严谨，没有结合实际情况选择合适的字段类型，导致在该场景下无法选择最优执行计划。 | 和业务侧确认，修改字段类型。 |
执行时间对比
| 数据量:2千万 * 6 | 单位：s |
|---|---|
| 优化前 | 254 |
| 优化后 | 1.5 |
| 性能提升 | 169倍 |
AntDB内核参数优化
在产品落地，性能优化过程中，除了优化不同场景下的SQL，也对AntDB的内核的参数进行了优化，增强了AntDB的健壮性，同时也增强了执行的效率。
结语
在去“O“及自主可控的大趋势下，AntDB数据库必将在更多的场景中得到更多的应用，当前AntDB更多地在数据分析统计的场景中展现它的魅力，鉴于AntDB的内核比Mysql更快更稳定，同时完美兼容Oracle语法，在中国电信集团研发中心主推基于Mysql的分布式数据库应用到核心业务系统的背景下，AntDB承载省级的核心业务数据是未来的努力目标。
