CMU《数据库系统导论》(2019) by Andy Pavlo Lesson 11 个人笔记

CMU《数据库系统导论》(2019) by Andy Pavlo Lesson 11 个人笔记

作者 AlexFisher

1.对两张table进行join时，我们称较小的表为外表/左表。

2.经典的join操作生成的每个元组由对应的key和组成它的两个元组的id组成。如：select r.name, s.age from r,s where r.age=s.age，则生成的元组格式是:s.rid,s.age,r.rid.但近几年有一些数据库选择直接存储目标数据而非pageid，因为通过id访问对应页获取数据的IO代价较高（访问存储在云端的数据比访问disk还要慢很多）。

3.join算法：

假设外表共有M个page，m个元组
内表共有N个page，n个元组

1.Nested Loop Join

Simple版本：两层for循环，外表在外层。

IO次数：M+m*N (Andy锐评：retard()

Block版本1：四层for循环，外两层为外表和内表的Page，内两层为在该两个Page内的元组。

IO次数：M+M*N

Block版本2：如果buffer最多存B个Page，则使用B-2个Page在外表。最外层改为B-2个Page。

IO次数：M+(M/(B-2))*N

Index版本：假设查询的条件是两个表的某一对键值相同：如果内表在连接的键上有索引的话，则可以通过两层循环，外层为外表元组，内层为内表所有值与外表键的值相同的元组。

IO次数：M+C*M，C为索引查询的复杂度：例如哈希为常数，B+tree为log(n)

2.Sort-Merge Join

分为两个阶段：

阶段1（sort)

对两张表基于连接的key分别进行排序（可以用之前提过的IO友好的分治排序）

阶段2(merge)

对两张表分别存两个指针，进行扫描匹配。对一些情况（例如外表有两个连续相同的key）可能会需要回退。

IO次数：

排序：外表：2M(logM/logB)，内表：2N(logN/logB)
合并：M+N(roughly)
如果某张表已经按key排好序（比如在该key上存在索引）或者查询有order by key，则可以免去排序复杂度。

worst case

某张表在对应key上的大多数值都相同且和另一张表多个值相同，则需要多次回退，可能退化成M*N复杂度。因此需要优化器分辨出这种情况，使用nested loop join。

3.Hash Join(the best one in most cases)

基础版本：

对外表中所有元组使用哈希函数a建哈希表。对内表元组使用a哈希得出值，找到哈希表该值对应的外表元组。
如果数据采用行存储，则更适合在哈希表中存储元组；如果数据采用列存储，则更适合在哈希表中存储元组指针。（可能因为列存储可以进行高效压缩，所以读入对应元组数据大概率无需返回磁盘）

优化：使用bloom filter检测内表元组哈希值是否存在在哈希表中（概率check 只会假阳性 super useful）

原理不多介绍，网上有很多，笔者的数据库老师在课上也有讲到。
bloom filter 很小，可以装进cache，所以比真正查哈希表快很多，并且无需IO。

grace hash join（针对整个哈希表无法存放在内存的情况）

对内外表中所有元组使用哈希函数a建哈希表。值相同的元组会映射在同一个partition中。因此对外表的partition i和内表的partition i内部元素进行匹配即可。如果单个partition无法存放在内存，则可以递归的再次使用新哈希函数进行分组。

IO次数

3*(M+N)
建立两个哈希表：2*(M+N)
对partition进行匹配：M+N

哈希表类型选择

如果已知表的大小则可以使用静态哈希，如果不知道表大小则可能需要使用可扩展哈希。