上一篇博客中实现了单线程 B+ 树的查找、插入、删除和迭代操作,这篇博客将完成实验二的剩余任务:并发 B+ 树。实现 B+ 树并发访问最简单的方法就是在整棵树上加一把大锁,但是这样会导致过多线程处于阻塞状态,严重降低 B+ 树的性能。这篇博客将使用蟹行协议(crabbing protocol)实现并发。 蟹行协议 该协议...
得益于我一直当多线程做的,从一开始就考虑并发问题,所以最后最难的 Task 4 虽然还是出现了 bug 但并没有浪费我太多的时间。 PS: 今天上网搜索 CMU15445 的时候发现 CMU15445 Fall2023 的官网都已经有了,顿时心头一紧! 言归正传: 这个Checkpoint 我们要完成的是 B+ Tree 的删除逻辑 迭代器 以及 最难的并发...
lab地址:Project #2 - B+Tree | CMU 15-445/645 :: Intro to Database Systems (Fall 2022) 课件:15445.courses.cs.cmu.edu B站讲解视频:08-索引并发 [中文讲解] CMU-15445 数据库内核_哔哩哔哩_bilibili Task #4 - Concurrent Index 这一节要基于latch crabing策略把单线程的B+树更新为多线程,实现索...
因此project2里要实现的主要是B+tree的并发保护。在正确地实现B+树的基础上用锁对数据进行保护。 最简单的方式是对整个树进行加锁,而对header page即对整个树进行加锁;显然可以看到逻辑结构的表跟物理结构的tree是一一对应的; 但是这样以来并发性显然很弱,因此实际每个page都持有锁,尽量只加必要page的锁,以提高并...
首先我还是来讲一下B+树,并发INDEX的算法。 https://15445.courses.cs.cmu.edu/fall2018/slides/09-indexconcurrency.pdf 首先LATCH,是用来保护DB自己需要保护的数据的,LOCK是用来保护CLIENT的TRANSACTION的 LATCH 分为读,写2个模式。可以有多个读锁,但是写锁是排他的。
一般一种数据结构,都有特定的不变量,比如BST,比如红黑树。 B+树也不例外。 我们可以根据B+数的特性,得到每一次插入,删除操作后 B+树应该满足。 每个PAGE的SIZE 满>= MIN SIZE, <= MAX SIZE 每个PAGE里面的元素是有序的。 INTERNAL PAGE指向左边的PAGE的最大值小于INTERNAL PAGE的KEY,右边PAGE的最小值,大于...
遵循课程指导完成即可。课程中最重要的部分之一是实验P2的b+tree优化。我通过引入乐观策略和改进bufferPool实现，将实验耗时从4.3s降低到2.1s。乐观策略通过更直接的锁申请和释放，提高了并发性能。同时，改进bufferPool实现，将index页的pin_count设置为2，避免频繁置换，显著提高了性能。
关于b+树优化，通过两条策略显著提升了运行时间。第一条策略为更乐观的乐观策略，放弃使用螃蟹协议，减少锁的持有时间。第二条策略在index页中增加pin，减少bufferPool相关操作，显著提高了并发度。P3实验（execution）涉及查询计划与表达式树生成，理解tuple、page、table的物理组织方式以及Schema类的交互关系...
上面提到的 latch crabbing 的方式简单直观,但是其问题也显而易见,那就是对 B+ 树更新的时候,每次都需要先对根节点加写锁,这对 B+ 树的并发性能造成了很大的影响。 这其实是一种悲观锁的策略,对根节点加写锁,是因为每次都假设我们的操作会涉及到 split/merge,但实际上,大多数情况下都不会有 split/merg...
B+ 树索引:B+Tree Index 查询引擎:Query Execution 并发控制:Concurrency Control 五个实验组成了一个用于教学的简单的关系型数据库 —— BusTub。实验方式基本都是实现一些规定的接口,跑通写好的测试用例。需要说明的是,代码中给的测试用例十分简单,基本只测试了一些主干路径,因此跑过了测试用例并不一定说明你代码...