在我的wsl上,我的朴素实现在运行一个测试时要花80s,加上乐观策略后,这个时间缩短到50s。 (你可以看到这个策略是在模仿b-link tree的下降部分。我后来又增添了right_link,来去除掉上面的分裂和删除所导致的乐观失败,不过效果不行,oj时间是3.1s,我更觉得这是机器的误差。之所以效果不行是因为在测试中,乐观失败的...
首先扯个题外话:最近几天累死累活调 B+ 树的时候发现总有个异常,我一直以为是 B+ 树实现的问题,没想到把 Buffer Pool 开大一点就过了,盯着输出 log 看了半天发现原来是 Project 1 的 Buffer Pool Manager 出了…
首先,上一个 task buffer pool 和这里的 b+tree 具体实现肯定不一样,关于具体的存储的层次也不一样; 在buffer pool 里,数据以 page 为单位,在 b+tree 中,每个索引结点而言,存储了很多的 key-value,每个 value 对应一个子节点(子节点是用 page_id 来标识),需要从 key 找对应的 page_id,这里 page_id ...
叶节点、内部节点发生borrow/merge 时,要先对兄弟节点加写锁,即使已经判断节点不安全且已经加了父节点的锁。这是因为父节点加锁可能在另一个操作释放锁到完成该操作之间;例如A,B是叶节点兄弟,t1删除叶子节点A的值,t2删除B的值,B是安全的,按照以下顺序 1)t2加父节点锁,发现B安全,释放锁; 2)t1加父节点锁,...
遵循课程指导完成即可。课程中最重要的部分之一是实验P2的b+tree优化。我通过引入乐观策略和改进bufferPool实现，将实验耗时从4.3s降低到2.1s。乐观策略通过更直接的锁申请和释放，提高了并发性能。同时，改进bufferPool实现，将index页的pin_count设置为2，避免频繁置换，显著提高了性能。
关于b+树优化，通过两条策略显著提升了运行时间。第一条策略为更乐观的乐观策略，放弃使用螃蟹协议，减少锁的持有时间。第二条策略在index页中增加pin，减少bufferPool相关操作，显著提高了并发度。P3实验（execution）涉及查询计划与表达式树生成，理解tuple、page、table的物理组织方式以及Schema类的交互关系...
重点讲解下homework2 里的b+树 是怎么分裂和合并的。 https://15445.courses.cs.cmu.edu/fall2018/files/hw2-clean.pdf image.png 综上需要走4个指针。 image.png 第一题解 image.png 第二题解 先找到18要插的叶子节点,随后发现满了。开始做分裂,前半部分和后半部分断开,后半部分的指针指到19.前半部分...
综上B+树的删除写完了。我们还需要去PAGE里实现,PAGE的子方法。 叶子节点的比较简单粗暴,就是直接移动,然后更新NEXT PAGE ID即可。和MOVE HALF TO 差不多的套路,复制下来改改就好。 image.png 而INTERNAL的要麻烦一些。 在调用MOVE ALL TO的时候,因为第一个节点是INVALID的节点,我们需要先去把PARENT指向这个PAGE...
得益于@迟策的贡献，项目中加入了完整的SQL层，使得BusTub从课程项目升级为真正具备SQL功能的数据库，用户可在BusTub上直接执行SQL查询，体验地址：BusTub Shell。在接触数据库内核入门课前，我SQL知识有限，对索引B+树、意向锁等概念也不熟悉。但最终，我从底层实现了所有功能。从九月份开始，经过了两三...
探讨B+树的实现。Task1 定义B+树的页类及其基类。Task2a 实现B+树的插入和查询功能。Task2b 专注于B+树的删除操作。Task3 实现重载索引访问的迭代器，重点在叶子结点上。lab3 完成查询完整过程，包括语法解析、绑定、计划阶段和优化。Task1 实现增删改查算子，如projection_executor、seq_scan_...