[Oracle] 关系型数据库排序算法和数据结构以及关联查询

关系型数据库排序算法和数据结构以及关联查询

1. Merge sort

理解merge sort算法将有助于更好地理解数据库join操作 - merge join

算法逻辑

将2个有序的大小为N/2的队列合并为N元素的有序队列



上面是排序最后的8元素数组, 仅仅需要重复一次2个4元素的数据排序(4元素已经是有序的了):

比较2个数组中的第一个元素

将较小的一个元素放在有序的8元素队列中

然后再从较小的元素所在的4元素数组中拿到下一个元素

将第三步中拿到的元素与第一步比较中较大的元素再比较, 将较小的一个元素放在有序的8元素队列中

重复上面的步骤, 直到其中一个数据比较完成

下面是实现的伪代码:

array mergeSort(array a)
if(length(a)==1)
return a[0];
end if

//递归调用
[left_array right_array] := split_into_2_equally_sized_arrays(a);
array new_left_array := mergeSort(left_array);
array new_right_array := mergeSort(right_array);

//将2个小的有序的数组合并为一个大的
array result := merge(new_left_array,new_right_array);
return result;

Merge sort将一个问题分为小的问题, 然后找到小问题的结果, 最终得到原始问题的结果. 其实是一个两阶段的算法:

分裂阶段: 大数组被分裂为小数组

排序阶段: 小数组合并为有序的大数组

分裂阶段

在分裂阶段, 数组被分裂为单一的数组需要3步, 这里的复杂度是log(N) (N=8, log(N)=3)

排序阶段

排序阶段, 成本是N=8的操作.

第一步需要4次merge, 每次花费2个操作

第二步需要2次merge, 每次花费4个操作

第三步需要2次merge, 每次花费8个操作

log(N)步merge, 总的花费N*log(N)个操作.

2. Arrary

现在流行的数据库都提供用数组来存储表, 例如: 堆组织表(Heap-organized tables), 索引组织表(Index-organized tables), 但这并不解决快通过多列来速搜索特定的条件;

3. Tree

B-Tree

在二叉搜索树中,

所有的节点键值都大于左边子树的节点键值

所有的节点键值都小于右边子树的节点键值



这个树有N=15个元素, 如果搜索208的过程是:

从根节点开始(key=136), 由于136<208, 因此应该搜索跟节点右侧的子树

由于398>208, 因此应该搜索节点398左侧的子树

由于250>208, 因此应该搜索节点250左侧的子树

由于200<208, 因此应该搜索节点200右侧的子树, 但是节点200没有右侧子树, 因此值208不存在

搜索的算法复杂度是log(N)

B+Tree Index

B-Tree最大的问题是无法做range query(范围搜索), 另外如果搜索2个值, 就需要进行完成的2次跟节点开始扫描的过程.

在B+Tree搜索中,

只有叶子节点存储数据信息

其他非叶子节点只是搜索中的一个路由信息



B+Tree的节点是有序的以及平衡的, 这也引来了一个问题: B+Tree的分裂

4. Hash table

用hash table来快速查找一个值是非常有效的, 一个好的hash函数可以做到搜索复杂度是O(1); 理解hash table可以更好的理解数据库表链接操作 - hash join; 这个数据结构在数据库中被用来存储内部的东西(譬如: lock table或者buffer pool);

构建一个hash table需要定义:

元素的key值

key的hash function (计算hash key的函数, 可以得到元素的位置信息, 一般叫做桶(buckets))

key的比较函数 (当找到对应的bucket后, 需要在bucket中查找元素)



最大的挑战是定义一个好的hash function, 得到包含尽可能少元素的buckets串;

Arrary vs hash table

hash table可以**half loaded in memory, 剩下的buckets可以在disk上

而数组则需要在内存中使用连续的空间, 如果需要加载一个large table, 那么很难做到有足够的内存空间

hash table可以选择所需要的key

5. 关联查询

传统的关系型数据数据有3种常见的关联操作: Merge Join, Hash Join, Nested Loop Join.

Nested loop join

Outer relation的每一行都会去扫描Inner relation, 输出匹配的记录

伪代码如下:

nested_loop_join(array outer, array inner)
for each row a in outer
for each row b in inner
if (match_join_condition(a,b))
writer_result_in_output(a,b)
end if
end for
end for

因此这是一个嵌套迭代, 时间复杂度是O(N*M) //加入outer relation有N行, inner relation有M行

在磁盘I/O上, outer relation里N行中的每一行, inner loop都需要读取inner relation里M行, 这个算法需要从磁盘读取N+N*M行, 如果inner relation足够小, 可以cache在buffer里, 那么只需要读取磁盘M+N行.

上面这个算法是最基本的, 但是如果inner relation过大而无法cache到memory, 下面这个是对磁盘更友好的算法:

代替一行一行的读取

每次批量读取并且cache到memory

在内存cache的批量数据里比较outer bunch的每一行是否匹配inner bunch, 输出匹配纪录

再从disk load新的批量数据进入memory

直到disk上没有数据

伪代码如下:

// improved version to reduce the disk I/O.
nested_loop_join_v2(file outer, file inner)
for each bunch ba in outer
// ba is now in memory
for each bunch bb in inner
// bb is now in memory
for each row a in ba
for each row b in bb
if (match_join_condition(a,b))
writer_result_in_output(a,b)
end if
end for
end for
end for
end for

这个版本的时间复杂度没变, 但是减少了磁盘操作.

Hash join

Hash join将会更复杂一些, 但是在很多情况下比Nested Loop Join有更少的成本开销



得到所有inner relation的元素

在内存中构建hash table

一个一个得到outer relation的元素

用hash funcation计算每一个outer relation的元素, 找到关联的inner relation bucket

比较bucket中的元素是否与outer relation中的匹配, 匹配则输出

时间复杂度: (M/X)*N + cost_to_create_hash_table(M) + cost_of_hash_function(N), 如果hash function足够好, 得到足够小的buckets, 那么时间复杂度是: O(M+N)

Merge join

Merge Join是唯一会产生排序操作的链接操作

Sort Join Operation: 根据join key来排序

Merge Join Operation: 将排序的结果merge在一起

Sort

前面已经描述过sort过的过程了, 在Merge Join中往往很多时候数据结果集已经是有序的, 譬如:

如果表本身就是有序的, 譬如IOT表(index-organized table)的join列

join条件是有索引的

基于有序的中间结果的join

Merge Join



Merge Join本身和前面的Merge Sort是很类似的, 但这次, 只是在2个集合中挑选相等的元素出来, 而不是从2个集合中拿所有的元素.

比较2个集合中当前的元素(当前指的是首次, 第一次)

如果相等, 结果中输出元素, 下来比较2个集合中下一个元素

如果不相等, 在较小的元素的集合中去下一个元素来比较(由于集合都是有序的)

重复上述, 直到任一集合中到最后一个元素

如果2个集合都是有序的, 那么时间复杂度是: O(M+N);

如果集合需要排序, 那么时间复杂度是: O(N*Log(N) + M*Log(M));

mergeJoin(relation a, relation b)
relation output
integer a_key:=0;
integer b_key:=0;

while (a[a_key]!=null or b[b_key]!=null)
if (a[a_key] < b[b_key])
a_key++;
else if (a[a_key] > b[b_key])
b_key++;
else //Join predicate satisfied
//i.e. a[a_key] == b[b_key]
//count the number of duplicates in relation a

integer nb_dup_in_a = 1;
while (a[a_key]==a[a_key+nb_dup_in_a])
nb_dup_in_a++

integer nb_dup_in_b = 1;
while (a[a_key]==a[a_key+nb_dup_in_b])
nb_dup_in_b++

//write the duplicates in output

for (int i = 0; i<nb_dup_a; i++)
for (int j = 0;i<nb_dup_a; i++)
write_result_in_output(a[a_key+i], b[b_key+j])
a_key=a_key + nb_dup_in_a-1;
b_key=b_key + nb_dup_in_b-1;

end if
end while

哪一种Join算法是最好的呢?

几个关键因素:

空闲内存大小: 没有足够的内存基本可以和强大的hash join说再见了(hash join至少需要full in-memory)

2个数据集合的大小: 如果是一个大表和一个小表, nested loop join将会比hash join快(hash join会有更大代价的构建hash table); 如果是2个大表, nested loop join将是非常耗cpu的

join条件是否存在index: 如果2个集合均有B+Tree, 那么merge join将会是更好的选择

结果集是否需要排序: 即使处理的是乱序的数据集合, 由于结果集需要有序, 可能也会使用成本更高的merge join

数据集是否有有序的: 如果是, 那么merge join将是最佳的选择

数据分布: join条件的列是否是倾斜的(譬如join条件是last name, 但是很多人拥有相同的last name), 那么使用hash join将是很有效的