Join 操作一般有三种实现策略
- nested loop -- 2层循环 遍历 R 和 S 表 (广泛使用)
- sort-merge -- 先对R,S 表进行排序, 在归并
- hash-based 基于哈希
Nested Loop Join (连接操作最基本的算法)
Using a page-by-page scan of the outer relation.
For each outer page, do a page-by-page scan of the inner relation
选 R,S 中较小的一个 作为 the outer relation, 较大的作为 the inner relation
Result = {}
// 在 R 表中 读 1 块 block 进入内存
for each page i in R {
pageR = getPage(R,i)
// 在 S表中 读 1 块block 进入内存
for each page j in S {
pageS = getPage(S,j)
for each pair of tuples tR,tS
from pageR,pageS {
if (tR.a == tS.b)
Result = Result ∪ (tR:tS)
} } }
基于块的嵌套循环的连接算法就是,每次读R表中一个block进入内存, 就把S表中,所有block依次读入内存进行比较操作, 所以S表一共被读入了 次。
I/O复杂度
cost = (一般把小的表 作为)
内存需求:
这种算法的内存需求很小, 最低只要 3 block , 2块分别给R,S作为input, 一块作为output输出result.
Block Nested Loop Join
如果 两个关系 都不能存入内存 ,
- 将 R表 切分为 大小为 N-2( N:memory buffer ) 的若干个子集合 --- 个子集合
- 内存中 N-2为 , 1 为 , 1 为 output buffer.
Nested Loop join算法内存需求很低,并没有充分利用内存。
如果能把R,S中较小的一个表完全读入内存, 那么只要1 个block 遍历 一遍S表就可以完成join , 这也是理论上 R Join S 的最低 I/O 开销---, 需要满足 .
如果 , 我们就依次读入 N-2 块 R page, 在 遍历 S 表, 如此重复,一共需要 次 读入 S 表。
所以总的 I/O 复杂度为
内存需求:
这里明显是 内存拉满,减少 buffer 会导致 读入R 表轮次上升,从而导致 cost 上升。
Index Nested Loop Join
上面 2种算法 有一个问题 , 都要线性的依次读入整个S表的所有 page 到内存与R比较才能防止遗漏,如果 能在S表上加入索引(稀疏 或者稠密索引), 依靠索引能减少读入 S表的page 数量, 这样就可以节省 I/O开销。
for each tuple r in relation R {
use index to select tuples
from S where s.j = r.i
for each selected tuple s from S {
add (r,s) to result
} }
I/O 复杂度为
表示根据索引找到与该 记录相match的 所需要的一次开销。 比如,S表该连接键上有个 cluster B+ 树索引, 在B+树上检索出 相应的 地址需要2 次操作, 根据地址找到对应记录 并与 相比较需要1 次操作, 那么 就等于2+1 = 3.
Sort-merge Join
Sort-merge 算法分2步
- 对 R, S 表进行排序 (多路归并排序)
总cost :
2.两个排序表的merge
- Best case :
- Worst case:
grace hash join
grace hash join 为了保证散列函数的性能, 对内存有最低要求,即:
.
-
使用 散列函数 h1 对 R, S 进行分区。
-
使用散列函数 h2 把R表的所有分区都映射入内存中 ,再依次映射S表的每一个分区.
Cost of grace hash join:
- partition relation R : 一读一写
- partition relation S: 一读一写
3.probe/join :
总开销: