CMU 15445 Project2 B+Tree

文章目录

      • Task 1 实现三个页面类的一些函数
      • Task 2 实现页的查找和插入
          • 2.1 查找
          • 2.2插入
          • 2.3删除
      • Task 3 迭代器实现
      • Task 4 并发控制
      • 优化
      • BUG
      • 总结

课程地址
在开始项目之前首先要先了解 B+树的概念,同时项目中还有可以打印当前B+树的函数,可以用来找BUG,
CMU 15445 Project2 B+Tree_第1张图片

Task 1 实现三个页面类的一些函数

b_plus_tree_page: 是leaf和internal的公共函数,其中只有GetMinSize这个函数需要注意,根据课程给出的B+树例子,其最小值是不一样的。同时根节点不需要满足最小Size,根节点的判断留到后面函数里面去判断,这边就只判断叶节点和内部节点、

leaf_page:最小值是 ⌊ M a x S i z e ⌋ / 2 \lfloor MaxSize \rfloor/2 MaxSize/2 internal_page:最小值是 ⌊ M a x S i z e + 1 ⌋ / 2 \lfloor MaxSize+1 \rfloor/2 MaxSize+1/2

b_plus_tree_internal_pageb_plus_tree_leaf_page:这两个页面需要注意的就是array[1]柔性数组,一开始对这个也是有点懵,后面了解了之后就当作一个数组用就行,其他的函数到后面慢慢添加就行。其中在内部节点存储的Value就是PageId。

Task 2 实现页的查找和插入

2.1 查找

上一个Project中BasicPageGuard提供了类型转换的方法:可以将获取的页转换为leaf_page 或者 internal_page

 BasicPageGuard guard = bpm_->FetchPageBasic(next_page_id);
 auto page = guard.AsMut();

踩坑点:由于在Project1中,我们实现了FetchPageRead和FetchPageWrite两个函数,可以分别对页面添加写锁和读锁,想结合后面的并发控制一起直接写了,但是由于函数的设计问题和获得的WritePage和ReadPage析构就解锁了,不好控制加锁和解锁,索性后面就全部使用FetchPageBasic。
B+树的查找、插入和删除都有一个共同特点,都是首先找到值对应的叶节点。

所有可以编写一个根据Key找到,该key所属叶节点的函数。

GetPageLeaf:可以使用一个while循环来逐步从根节点,迭代到叶节点。

有了GetPageLeaf函数后,查找函数就很好写了,直接在获取后的叶节点上查找是否包含Key即可。

在开始其他项目之前首先要先了解B+树的概念,同时项目中还有可以打印当前B+树的函数,可以用来找BUG,

2.2插入

仔细查看前面给的B+树例子,需要注意的是,对于叶节点,当到达MaxSize是就需要分裂,而对于内部节点需要达到MaxSize+1才需要分裂。

Insert函数的实现流程图如下。 需要注意的点就是内部节点和叶节点的区别,同时内部节点为了保持Key和Value的数量一致,array[0].first是没有用的,不过我们可以将它当作一个标志位。

CMU 15445 Project2 B+Tree_第2张图片

2.3删除

在做删除之前,还是使用项目给出的网站查看删除的情况,可以看到主要就分为两种情况,一种就是咸香左右兄弟节点借,如果兄弟节点的Size>MinSize,则借,如果左右兄弟节点都不满足,就需要采用合并的策略。

情况 1

CMU 15445 Project2 B+Tree_第3张图片

情况 2

CMU 15445 Project2 B+Tree_第4张图片

下面是Remove函数的流程图:

CMU 15445 Project2 B+Tree_第5张图片

需要注意的点就是,在借节点时,借的左兄弟节点,则借最后一个key,若借的是右兄弟节点,则借第一个key(这里可以用上前面内部节点的第一个key)。同时父节点更新的地方和值也不一样,通过画图就可以知道,这里就不在赘述了。

在合并时也是一样,要区分和左兄弟节点合并还是和右兄弟节点合并。同时删除父节点中的key。

相较于2022fall,2023spring中的page中删去了ParentId成员,对于插入,删除都不需要考虑更新Parentid的情况,减少了很多代码的编写。

Task 3 迭代器实现

项目中对迭代器的实现好像不需要要求并发控制,所以实现起来就比较简单了。

page_id_t page_id_ = INVALID_PAGE_ID;  //当前迭代器所属的page_id
B_PLUS_TREE_LEAF_PAGE_TYPE *leaf_page_ = nullptr;
int page_index_ = 0; // 在页中的位置
BufferPoolManager *bpm_ = nullptr;

往.h文件添加上述成员变量,使用INVALID_PAGE_ID来表示迭代器到达END。

operator==:只有在page_id和page_index都相等的时候迭代器才相等。

operator++:需要注意++可以会导致迭代器从一个页面,跳到另一个页面,所以需要注意更新成员变量,因为在实现的时候就能从页面获得NEXTPAGEID,所以该task也不是特别难。难的地方在于理解题目所要实现的目的。

Task 4 并发控制

在开始并发控制之前,需要确保前面的实现没有问题,可以在每个函数前加一把大锁,提交到gradescope看看自己的实现是否正确。

课上也是同样给了两种加锁方案:

CMU 15445 Project2 B+Tree_第6张图片

CMU 15445 Project2 B+Tree_第7张图片

基础算法 先给自己加锁,在判断为安全节点后,才能释放祖先节点的锁。

改进算法 因为分裂的情况发生的占比较少,所以一开始乐观的认为都是安全节点,加读锁,当叶节点不安全时,再像基础算法一样一步步加写锁。

安全节点定义:

读:都是安全的

插入:当节点数量小于MaxSize-1时是安全的(internal节点为小于MaxSize)

删除:当节点数量大于MinSize都是安全的

当然,根节点的情况需要另外说明,删除时根节点时叶节点则>1是安全的,内部节点>2是安全的。

根节点的保护

因为再插入和删除这些操作之前都要判断B+树是否为空。

  1. 该项目提供了一个BPlusTreeHeaderPage类,可以用该类来充当根节点的父节点,也能使用page的加锁,解锁方式。
  2. 可以定义一个读写锁来当作根节点的父节点来保护根节点。

unlock和unpin

第一次实现的时候先unpin在unlock导致,在测试的时候一直报错,找了好久都找不到问题在哪,后面在其他的博文中找到答案,如果先unpin,pin_count=0该页面可能会被换出,导致页面失效,无法unlock。

优化

  1. 使用一把大锁,提交后得分50000多,排在倒数~~~~~
  2. 使用基础螃蟹算法优化,提交后得分接近90000,好像还是倒数~~~~~
  3. 因为统一使用了AsMut,会将读取的页面置脏位为true,将一些安全节点脏位改为false,减少磁盘的读写,提交后分数有104000了,但还是倒数~~~~~
  4. 乐观锁算法//TODO

BUG

  1. pageguard上的&& 要把page置为nullptr 不然会重复释放锁 造成不定义的行为 卡住

总结

Project 2完成的时间比Project 1长了一倍花了20天左右,当然因为对于一些概念性的理解花了较多的时间,一个是删除画的时间多一点,另一个就是并发控制一大半的时间就花在这了,因为看到2022fall中存储了ParentId,所以使用了一个map来存储各个节点的ParentId,一把大锁提交Grapescope,满分通过后,就开始使用改进算法,因为死锁还花了一些时间排查,死锁解决后就总是出现一些莫名奇妙的bug,都不知道从哪入手,后面发现map是线程不安全的,所以在每次读写map时我都加了一把额外的锁。

这把锁真的要我的老命,加入这把锁后,因为有些test的线程太多,好多线程都停在lock中,而占据了很多buffer pool中的空间大小,导致无法换出页面,到最后才发现真的项目用到ParentId的地方特别少,遂删除map,才通过测试。(这边消耗的时间差不多花了五天,还是太菜了)。

最后目前的优化效果还不是特别好,等有时间了回头再来搞搞优化。

  1. 会不会是Project 1中使用1把大锁的缘故?
  2. 不论在插入、删除、查找都将页面统一置为脏会不会增加了很多磁盘的读写?

你可能感兴趣的:(CMU,15445,数据库,c++)