首页 > 代码库 > 关系代数的并行计算

关系代数的并行计算

DremelImpala的学习引申出了SQL查询的并行执行问题,于是借此机会深入学习一下关系数据库以及关系代数的并行计算。

SpeedupScaleup

Speedup指用两倍的硬件换来一半的执行时间。Scaleup指两倍的硬件换来同等时间内执行两倍的任务。但往往事情不是那么简单,两倍的硬件也会带来其他问题:更多CPU带来的长启动时间和通信开销,以及并行计算带来的数据倾斜问题。


多处理器架构

共享内存:任意CPU都能访问任意的内存(全局共享)和磁盘。优点是简单,缺点是扩展性差,可用性低。


共享磁盘:任意CPU都能访问任何的磁盘,但是只能访问自己的主存。优点是可用性和扩展性比较好,缺点是实现复杂以及潜在的性能问题。


不共享:任意CPU都只能访问自己的主存和磁盘。优点也是扩展性和可用性,缺点是实现复杂以及复杂均衡。


混合型:系统整体上是shared nothing架构,但结点内部可能是其他架构。这样就混合了多种架构的优点。


数据分区

数据分区的目的就是:让数据库能够并行地读写数据,最大程度地挖掘I/O的潜力。常见的分区算法有:round-robin、范围索引、哈希。


关系运算并行化

关系代数自身的属性允许关系操作的并行化


并行查询处理主要分为四步:

?  翻译:将关系代数表达式翻译成查询树。

?  优化:重排join顺序,并选择不同join算法来最小化执行开销。

?  并行:将查询树转换成物理操作树,并加载到处理器。

?  执行:并行运行最终的执行计划。

首先将一条SQL语句翻译成查询树。


然后根据表大小、索引等情况,重新排列join顺序,并选择合适的算法。


关于join算法,常见的有以下几种:

?  Nested Loop join:思路很简单,相当于两层循环遍历,外层是驱动表,返回满足关联条件的行。适用于驱动表小(经过条件过滤后),而被驱动表上join字段有索引的情况。在两表都很大时效率很差。

for each row R1 in the outer table
    for each row R2 in the inner table
        if R1 joins with R2
            return (R1, R2)

?  Sort-merge join:思路也很简单,就是按join字段排序,然后进行归并排序。当join字段存在重复值时,相当于每个重复值形成了一个分区。Join字段是否排序和重复值的多少决定了sort-merge的效率。适用于两表都很大的情况,尤其当join字段上存在聚集索引时(相当于已经排好序了),效率很高。算法主要消耗在磁盘上。

?  Hash join:类似于存在重复值情况时的sort-merge,只不过是人为的使用哈希函数进行分区。思路是扫描小表建立哈希表(build阶段,小表也叫build),然后逐行扫描大表进行比较(probe阶段,大表也叫probe)。适用于两表都很大又没有索引的情况,限制是只适用于等值连接。算法主要消耗在CPU上。


此外,对于子查询还有semi joinanti join等算法。

 

最后将查询树变成物理操作树,也就是真正的执行计划。然后根据集群的资源情况,调度到合适的结点上进行并行计算。


参考资料

1 Parallel Query Processing

 

关系代数的并行计算