引言

本系列为 CMU 15-445 Fall 2022 Database Systems 数据库系统 [卡内基梅隆] 课程重点知识点摘录，附加个人拙见，同样借助CMU 15-445课程内容来完成MIT 6.830 lab内容。

本节开始之前，先看一下目前课程的进度状态：
在这里插入图片描述
为了支持 DBMS 更高效地从 pages 中读取数据，DBMS 的设计者需要灵活运用一些数据结构及算法，其中对于 DBMS 最重要的两个是：

它们可能被用在 DBMS 的多个地方，包括：

在做相关的设计决定时，通常需要考虑两个因素：

Hash Tables

Hash Table 主要分为两部分：

Hash Function：
- How to map a large key space into a smaller domain
- Trade-off between being fast vs. collision rate
Hashing Scheme：
- How to handle key collisions after hashing
- Trade-off between allocating a large hash table vs. additional instructions to find/insert keys

由于 DBMS 内使用的 Hash Function 并不会暴露在外，因此没必要使用加密（cryptographic）哈希函数，我们希望它速度越快，collision rate 越低越好。目前各 DBMS 主要在用的 Hash Functions 包括：

当 keys 可能出现重复，但 value 不同时，有两种做法：

Separate Linked List（分离链表）：这种方法使用链表来处理哈希表中冲突的情况。当发生冲突时，即多个键被映射到同一个哈希桶（存储位置），它们将被存储在一个链表中。每个节点包含键和对应的值。通过遍历链表，可以在哈希表中找到具有相同键的不同值。这样，即使键相同，不同的值也可以被存储和访问。
Redundant Keys（冗余键）：这种方法在哈希表中允许存储相同的键，但每个键都关联着不同的值。当发生冲突时，新的键值对可以被插入到相同的哈希桶中，作为已有键的一个冗余副本。通过遍历哈希桶中的冗余键，可以找到具有相同键的不同值。

如下图所示：
在这里插入图片描述
通常为了减少 collision 和 comparisons，Hash Table 的大小应当是 table 中元素量的两倍以上。

Robin Hood Hashing: 是 Linear Probe Hashing 的变种，为了防止 Linear Probe Hashing 出现连续区域导致频繁的 probe 操作。基本思路是 “劫富济贫”，即每次比较的时候，同时需要比较每个 key 距离其原本位置的距离（越近越富余，越远越贫穷），如果遇到一个已经被占用的 slot，如果它比自己富余，则可以直接替代它的位置，然后把它顺延到新的位置。

本部分参考: 布谷鸟哈希（Cuckoo hash）

首先要理解布谷鸟的行为，这也是算法的核心:

布谷鸟哈希有几种变种，先介绍一个哈希桶和两个哈希函数的版本：

insert逻辑：

若值x已存在哈希表中，则直接返回
若insert后哈希表空间会不够，则先进行扩容，再rehash，再继续3、4、5
用哈希函数h1(x)计算出下标i1，当bucket[i1]为空时，说明鸟巢可用，插入x
若bucket[i1]非空，用新值x将bucket[i1]上的老值x’踢开（kick out），对应小布谷鸟将老蛋踢出巢穴，老蛋当然也不能坐以待毙，继续kick out别的蛋，老值x’的下一个位置用哈希函数h2(x)寻找
重复2，直到达到最大循环次数MaxLoop（插入失败）；或者所有被踢开的值都找到新位置（插入完成）

lookup逻辑：查找逻辑非常简单，去可能的两个巢穴里寻找，即去下标h1(x)和h2(x)寻找，若没有匹配上，则不存在（从这里可以发现查找是非常快的，且时间复杂度稳定是O(1)）

下图展示的是两个哈希函数，两个哈希桶的版本:
在这里插入图片描述
为了防止我们不会陷入一个无限循环中，一旦我们发现了一个死循环或者达到最大循环次数，我们就需要对现有的hash table进行扩容。