首页 > 代码库 > 关系代数的并行计算
关系代数的并行计算
从Dremel和Impala的学习引申出了SQL查询的并行执行问题,于是借此机会深入学习一下关系数据库以及关系代数的并行计算。
Speedup和Scaleup
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 join和anti join等算法。
最后将查询树变成物理操作树,也就是真正的执行计划。然后根据集群的资源情况,调度到合适的结点上进行并行计算。
参考资料
1 Parallel Query Processing
关系代数的并行计算