CMU-15445 LAB1:Extendible Hash Table, LRU, BUFFER POOL MANAGER

概述

最近又开了一个新坑，cmu的15445，这是一门介绍数据库的课程。我follow的是2018年的课程，因为2018年官方停止了对外开放实验源码，所以我用的2017年的实验，但是问题不大，内容基本没有变化。想要获取实验源码的同学可以上github搜，或者直接clone我的代码，找到最早的commit就ok了，仓库地址在文末。课程配套教材是《
database system concepts》， 最好看原版的，中文版的貌似页数和课程中的对不上。

言归正传，本lab将实现一个buffer pool manager，又分为三个子任务：

1. 实现一个extendible hash table
2. 实现一个lru page replacement policy
3. 实现buffer pool manager

extendible hash table

extendible hash table是动态hash的一种，动态是相对静态来说的。hash的原理是通过hash函数，f(key)->b，将key映射到一个bucket地址集合中，如果b集合选的比较小，那么当key增多后，越来越多的key会落在同一个bucket中，这样查找效率会下降。如果b集合一开始就选的很大，那么有很多bucket处于未满状态，浪费空间。为了解决这个问题，就引入动态hash的概念。
静态hash存在上述问题主要是hash函数确定好后就不能再变了。动态hash就没有这个问题。

数据结构

extendible hash table数据结构如下：

1. bucket address table是一个数组，保存bucket的地址。
2. global depth是一个整数值。
3. 每个bucket都有一个local depth也是一个整数值，且小于等于global depth。每个bucket能装的键值对的最大值为bucketmaxsize。

查询

比如要查找key=1对应的value值，首先取h(1)对应的二进制前global depth位，作为bucket address table的下标，找到存放该key的bucket，然后在相应的bucket中查找。

插入

如上图，假设bucketmaxsize为2.

最开始的情况如figure1，我们插入[1, v], [2, v]，因为这时global depth=0所以，全部落在bucket1中，也就是figure2。

在figure2基础上，再插入[3, v]，这时还是应该插到bucket1中，但是bucket1已经满了，同时bucket1的local depth = global depth = 1。这时先将bucket address table扩大一倍，同时global depth加1。然后重新创建两个新的bucket a, bucket b，local depth在原来local depth基础上加1（由0变为1），再将bucket 1中的[1, v], [2, v]分配到新的两个bucket中，分配规则如下：
如果h(key)的第local depth(1)位是0，那么放到bucket a中，如果为1那么放到bucket b中。分配完毕后，重新调整bucket address table中指向原来bucket 1的指针指向，这里index 0和1的指针原来都指向bucket 1，所以都需要调整，调整规则如下：
index的第local depth(1)位为0的指向bucket a, 为1的指向bucket b。
最后在插入[3, v], 假设h(3)的前global depth为1，那么插入到bucket b中。最终的效果如figure3。

在figure3基础上再插入[4, v]，算法和前面一样，假设[4, v]本应插入到bucket a中，但是bucket a满了，且global depth = bucket 1的local depth。所以先将bucket address table扩大一倍。然后重新创建两个新的bucket, bucket c和bucket d，再将bucket a中的[1, v], [2, v]重新分配到bucket c和bucket d中。在调整buckert address table指针指向，最后再插入[4, v]。最终效果如figure 4。

在figure4基础上，再插入[5, v], [6, v]，假设都落在bucket b中，那么插入[5, v]后bucket b将满，再插入[6, v]的时候bucket b已经满了。这时和前面不一样，此时global depth(2) > bucket b的local depth(1)。所以不需要扩大bucket address table。只需要创建两个新的bucket, bucket e和bucket f。将原来bucket b中的[3, v], [5, v]分配到bucket e和bucket f中。然后调整原来指向bucket b的指针指向bucket e和bucket f。最后在插入[6, v]。最终效果如figure 5。

lru page replacement policy

实现最近最少使用算法，说白了就是给你一些序列，比如1， 2， 3， 1，这时哪个是最近最少使用到的。可以画下图，越下面的越久没有使用到。先用了1，再用了2，那么2比1新，所以2在1上面，然后用了3，那么3应该在2的上面，最后用了1，那么把1从最下面调到最上面，同时2变到了最下面，至此2应该是最近最久没有使用的。

1            2            3            1
             1            2            3
                          1            2

那么用什么数据结构来存储呢？

先看下有哪些操作：

void insert(const t &value); 
bool victim(t &value);
bool erase(const t &value);

insert()：将value加到最顶部，或者如果value已经在队列中，将其提取到最顶部。
victim()：提取最近最久没有使用的元素，将最底部的元素弹出。
erase()：删除某个元素。

首先想到的是单向链表。但是如果用单向链表的话，victim()需要访问尾元素，单向链表每次都要从头到尾遍历一遍才能访问尾元素，性能可想而知。

用双向链表就可以解决这个问题，双向链表可以以o(1)的时间访问头尾元素。还有个问题，如果调用insert(v)，按照之前的算法，我先得知道v在不在这个双向链表中，如果不在直接插到头部，如果在的话，将其提取到头部。如果仅仅是双向链表，那么还是需要遍历一遍队列，查询v是不是已经在队列中了。

可以用一个map记录已经在队列中的元素到链表节点的键值对，这样就可以以o(1)的时间查询某个value是否已经在队列中。
最终确定数据结构如下：

buffer pool manager

为什么需要buffer pool manager

假设两种极端的情况：

1. 没有缓冲池，那么数据都位于磁盘上，第一次访问一页数据，需要将其从磁盘读取到内存，第二次在访问相同的页时，还需要从磁盘读，非常耗时。
2. 假设内存无限大，那么访问一页数据后，将该页数据直接保存到内存，下次再访问该页时，直接访问内存缓存就行。但是现实中内存比磁盘容量小得多，只能缓存有限个数据页，如下图内存只能缓存三个页，依次访问page 1, 2, 3, 现在已经缓存了page 1, 2, 3，假设想读取page 4，那么得先清空一个内存缓存页，用来缓存page 4的数据，那么清除谁呢？。这时候任务2的替换策略就派上用场了，根据lru替换策略，page 1是最近最久没有被使用过的，那么就将page 1重新写回到磁盘，然后将page 4读取到内存。
   

所以buffer pool manager的作用是加速数据的访问，同时对使用者来说是透明的。

具体代码就不贴了，可以参考我的实现：