南大通用GBase 8a查询性能优化的3种通用方法

从整体上看,GBase 8a数据库集群提升性能,包括查询,加载,更新等等,都归类到三类方法,按照重要程度如下:

1、优化业务SQL
2、优化数据库参数
3、增加更多的硬件

本文针对如上三类,根据项目经验,针对可能的优化点做出分析。

优化业务SQL

这类优化,包括业务SQL自身,表结构,数据等方面。

表结构

目前涉及到的主要是hash分布表的分布列选择,以及何时使用复制表的情况。

Hash分布表

选择好的Hash分布表,可以避免在做group, join时数据在各个计算节点间的一次额外的数据传输。

如果需要group或join的数据都在本地,则直接在本地做运算,只需要将计算结果发送到汇总节点即可。如果Hash列不正确,则需要做一次动态Hash:创建临时表,将每个计算节点需要计算的数据,根据需要分组的列,做一次数据重分布,然后在各个节点的临时表做计算。

如果数据量很大,则这个重分布的过程将额外花费一次磁盘读取、网络传输和接收方的磁盘写入。

建议的Hash列选择:
1、group 或者 join的列
2、该列唯一值很多。不能是大量的重复值

如果你的group、join列多个条件,那就选择最重要,使用频率最高的业务,唯一值最多的列做Hash分布列,常见的有IMSI,MSISDN,callingnumber, IDNumber等。

特殊情况:如果你有多个业务同样重要,那么可以考虑做多个表,分别用不同的Hash列对应不同的业务。

提示:GBase 8a V9版本开始支持多列Hash, 在某些场景下可以缓解数据单列Hash分布倾斜现象。

复制表

如果数据量不是很大,比如100万以内,或者数据量虽然较大,但变动很少。用途经常是作为基础表、维度表使用,那么建议用复制表。

复制表在每个计算节点有完整的一份,在与其它表做join时,无需在进行重分布。

另外如果是用于频繁查询的小表,数据量少但并发很高,也可以用复制表,加上连接的负载均衡,可以最大化提高并发数量。比如最终展示的结果报表。

Hash 索引

如果在大数量里,比如单个数据节点超过1000万,有明确的精确查询,其重复度低,结果集不多,可以建立Global Hash索引。

该索引只对精确查询有效,对范围查询,模糊查询等都无效。

行存列

如果业务最终要返回大量的列,比如查询详单,可以通过行存列grouped的方式,降低这类查询消耗的磁盘IO,提升这类查询性能。

全文索引

如果有频繁的like操作,且匹配的数据长度大于3个字符,可以考虑用全文索引。如果匹配字符太少,比如 like '%138%',就得根据测试评估了。

SQL写法

这类优化主要方向是,规避列存数据库的劣势,发挥其优势。以及一些实现相同功能的更高效的写法等方面。

减少不必要的数据使用

1、避免或减少select *

不要完全依赖数据库的优化,在SQL写法上,尽量避免select *的写法。特别是最终只使用有限的几个列。

去掉不必要的全排序order

同样不能完全依赖数据库的优化,特别是在一些嵌套的内部查询,全排序与否完全不影响最终结果。

请区分和最外层返回客户端结果集的业务区别,这个排序还是需要的。在业务允许的情况下,建议加上limit。

避免笛卡尔

join的顺序或关联字段,尽量保证结果集不要无限扩大导致笛卡尔。

比如两个表的性别做join,除非特殊业务,否则真的没有什么意义。

选择合适的group和join列顺序

如果group或join的有多个列,且不是hash分布表或者不包含hash分布列,那么就将重复值最低的列放在最前面。

比如 group by gender,phonenumber 应改写成 group by phonenumber, gender,因为手机号的重复值更低。

业务调度

批量加载处理

在允许的时间实时性要求范围内,尽量减少加载小文件的数量和次数。加载文件大小,考虑网速,磁盘性能,建议不低于1-10GB。

比如多个采集端口,生成各自的数据文件,在加载前可以合并成一个文件或尽量少的文件。这样在加载时,不仅仅数据源性能好,也减少了集群和数据源的通讯次数,提升了加载性能。

业务并发控制

需要开发和设计人员,控制并发。比如连接池大小,定时任务周期,任务先后顺序。

包括并发加载、并发查询、并发导出、并发后台处理。大型任务尽量在非重要时间(比如凌晨)进行。

优化数据库参数

通过调整数据库参数,提高或稳定业务性能。

并发控制

选择合适的并发数,不是高并发,一定带来高性能。

如硬件资源有限,比如特别是CPU,磁盘,过高的并发或导致内部竞争,CPU的表现是大量的Sys,磁盘的表现就是Busy100%但吞吐量很低。

整体并发参数

可以通过数据库的资源管控,限制同时运行的SQL数量,后续SQL是排队状态。

单个SQL并发参数

主要是内部线程并行度参数,以多少个内部现场处理一个SQL。高并发下可以考虑降低并行度,以降低资源竞争。

主要涉及和degree有关的参数

gbase_parallel_degree

gbase_loader_parallel_degree

详情可以参考数据库参数部分。

内存控制

在内存有限的前提下,。大并发必然会导致内存不足,在保证有限并发可用时,必须要调增数据库的内存参数,避免内存不足导致报错或者大量的SWAP导致性能急剧下降。

内存参数请参考 GBase 8a集群常见内存配置参数

增加更多的硬件

这个不用多说了,更好的硬件必然带来更高的性能,支持更多的并发。

建议:对重要业务,使用频率高的业务,通过表空间、虚拟集群等方案,将数据保存到更高性能的服务器或者硬盘上。

虚拟集群

通过虚拟机群的物理隔离,可以按照业务重要性,实时性要求,划分多个集群,来保证最重要的业务获得最高的硬件支持。

表空间

通过表空间,将重要的表保存到性能更高的磁盘上,比如ssd, flash卡等。

多实例

特别针对超多CPU,比如国产ARM平台服务器,超大内存,超过512GB,可以通过多实例部署的方案,提高硬件资源的利用率,包括numa绑定提高CPU和内存的高效利用。

参考

GBase 8a 数据库集群常用优化手段建议方法

GBase 8a集群86版本加载相关参数

GBase 8a集群查看所有节点正在运行的SQL