GBase 8c分布式数据库架构充分运用了每个节点的计算资源,且随着节点规模的扩大其整体性能也呈线性增长。为了实现分布式架构下性能和资源的最大化利用,GBase 8c提供了三种分布式执行计划,分别为FQS(Fast Query Shipping)计划、Stream计划以及Remote-Query计划,其中FQS和Stream是可以下推的计划,也就是说,集群中的所有DN都参与了SQL执行。

显然这两种执行计划可以实现节点资源的充分利用,二者之间的区别在于FQS计划是CN直接将原语句下发到各个或者部分DN上,各DN单独执行,相互之间没有数据交互,而Stream计划是原语句在CN上生成执行计划,然后CN将执行计划下发到各个DN上,各DN在执行过程中使用Stream算子进行数据交互。

至于Remote-Query计划,是一种折中的方案,语句在无法生成前两种执行计划的情况下,CN生成计划后,将部分原语句下发到DN,各DN单独执行,执行后将结果发送给CN,CN执行剩余计划。这种计划执行性能一般较差,使用较少。

对于分布式数据库而言,往往意味着应用场景多样化、数据规模庞大(PB级)、作业逻辑复杂及语句耗时较长等特征,尤其是针对金融行业,其大数据量及复杂作业决定了生产环境中Stream计划的广泛运用。

GBase 8c在stream执行计划有三个Stream算子:gather、redistribute和broadcast。正是基于Stream算子的合理运用,在分布式架构下大规模数据的处理才成为可能,但解决问题的手段往往也会产生新的问题,因此针对Stream算子的优化也成为GBase 8c中SQL优化的重要部分。在实际开发中优化SQL性能,我们常常需要借助explain命令分析执行计划,在分布式环境中尽量使用streaming执行计划,提升分布式计算资源的使用能力。

下文针对分布式执行计划的subplan两个具体案例展开分析。
案例1:原始SQL如下:
图片
通过explain analyze检查其执行计划如下:
图片

图片
可以看到,当前SQL执行时间约为28s左右,根据如图标红所示,SQL中三个子查询分别使用了pgxc执行计划,未能很好的使用GBase8c的分布式的streaming执行计划能力,造成效率低,并且可以看到执行计划中的3个subplan对应到上面的执行计划,造成改SQL执行计划效率低下,所以问题的关键就是如何消除subplan的pgxc执行计划,经过修改为如下,采用临时表的方式,同时影响的还有wm_contact系统函数无法下推问题,需要对SQL中无法正常使用streaming 下推执行计划的SQL进行改写后,采用临时表方式如下:
图片
再次通过Explain analyze看到执行计划发生了变化:
图片

图片
可以看到新的执行计划消除了3个子查询subplan对应的pgxc执行计划,采用了streaming执行计划,执行时间约降为600ms左右,效率得到了很大的提升,充分说明分布式的优势所在。

案例2

业务开发反馈在执行如下SQL对1个大表的数据更新操作时,执行性能比对原来ORACLE执行效率严重下降,执行时间小时级别:
1、执行 update zh_dhcplat.sp_org  a set Subtype=NULL
2、执行update zh_dhcplat.sp_org  a set Subtype=(select qylb from zh_cyzt.tpp_cyqyxx b where a.obj_id=b.id)where exists (select 1 from zh_cyzt.tpp_cyqyxx b where a.obj_id=b.id);

具体可以看到在执行SQL2时,更新约为68512条记录,但是耗时3686秒,差不多1个小时左右时间,确实更新速度很慢,该环境为3分片的GBase 8c分布式数据库集群环境。
图片
同样经过执行计划explain analyze方式分析可以得知,该问题主要由括号中的子查询引发,经过修改将SQL改成update from后执行计划发subplan消除,可以看到执行时间只需要3秒不到就更新完毕:
图片
从上面两个案例可以看到,分布式环境的上执行计划改变对SQL执行性能的影响是非常大的,以上案例是GBase 8c分布式环境开发过程中的2个子查询引发的执行计划效率低,从而造成了SQL执行时间长的问题,我们在优化过程中,需要通过SQL改写等方式,消除subplan或pgxc执行计划,充分运用分布式执行计划中的streaming计划,通过多节点并发提升SQL执行效率,在实际GBase 8c环境开发过程中,我们需要多使用explain工具对SQL执行计划进行分析,从而开发出高效率执行的SQL。 


读研的抽屉
1 声望0 粉丝