RedBase点滴

最新推荐文章于 2024-06-23 09:35:47 发布

lishuhuakai

最新推荐文章于 2024-06-23 09:35:47 发布

阅读量3.8k

点赞数 1

分类专栏： Sql

本文链接：https://blog.csdn.net/lishuhuakai/article/details/78446283

版权

Sql 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

RedBase是斯坦福数据库课程的一个Project,在网上找不到最初的代码,不过在github上有这个project的成品.很多大牛在推荐数据库实现的时候,大抵都会推荐一下这份源码,所以我就将代码clone了下来,准备动手来处理一下这些代码.

总而言之,就我得到的代码而言,这份源代码的质量真不敢恭维,看着看着我就坐不住了,忍不住想将这份糟糕的成品重构一遍,所以没有什么废话,直接就动手了.

这个Project一共分为5个模块,过去的一个月,拖拖拉拉,不过刚刚处理到第3个模块而已,所以要做的事情还有很多,我在这里立一个flag吧,我要在一个半月里完成这份代码的重构和阅读的任务,也就是说,在12月19号那天,对于这个Project要做的所有事情都要做完.

这个Project之后,精力会逐渐向工作的方面靠.我也终于快毕业了.

11月15日

B+树删除操作的实现是在是一件蛋疼的事情,从上个星期到现在,我陆陆续续已经写了一个星期了,基本上每天都在测试调试中度过,删除操作有非常多的corner case,一点很小的疏忽,程序就挂了,还有一点很痛苦的是,这个东西其实不太好调.有的bug在节点数目比较小的时候是显示不出来的,所以要尽力上大规模数据集的测试.

不管怎样,现在基本上已经达到了40000~50000个数据的插入和删除没有问题(或者说我的测试数据有问题,没有暴露出代码的bug),但是插入的数据更多的话,有几率程序会挂掉,说明代码里面还有bug,还是要继续测试.什么时候能撑过100000+数据的插入,即使代码里有bug,我也懒得去调试了.

但愿今天能够将代码的bug修掉.我也不想继续来测试了.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

代码bug应该消除了,我测试了180000+数据的插入和删除,程序暂时还没有发现任何问题.

我实现的B+树插入和删除是支持相同的key的,但是有一点,那就是两个key相同的entry所带的卫星数据一定要不一致,否则的话,完全一样的entry插入到树中没有太大意义.如果不支持相同的key,那么实现会相对简单很多.因为引入了重复的key,会导致很多的corner case,另外有一点值得一提的是,支持重复的key,删除的性能是要大打折扣的,试想这样一种情况,一棵都是相同的key,仅是卫星数据不同的entry组成的B+树,试图在树中找到一个entry,只有一个办法,那就是穷搜,当然,这是非常极端的情况.

11月16日

昨天写的B+树删除算法依旧有bug,我昨天晚上调试代码到凌晨4点,修复了大致2~3个比较严重的bug,但是即使如此,依旧昨天凌晨程序在大规模数据集的情况下,依然有几率崩溃,我那个时候人差不多是崩溃的,但是没办法,我知道,如果我不把代码完整地实现的话,我这个人会天天想着这件事情的,所以今天中午爬起来,我又开始调试了,为了调试B+树的删除,我已经写了几个版本的测试代码了,每一个版本比每一个版本严格,写到今天,我自认为,已经把所有能够想到的限制条件都用上去了,利用这个测试工具,我今天又揪出了2~3个bug,现在代码基本上已经不会崩溃了,测试了几轮,基本上没什么问题了.好了,这几天终于可以睡个好觉了.

我这里稍微提一下如何测试删除操作是否正确,首先,每个节点内的key的数目越小,越便于暴露bug,昨天我的限制是一个节点内最多只能有20个key,昨天晚上我想了一下,改成了每个节点最多只能够放5个key,这基本上已经达到极限了.结果这样一来,只需要10000多个key的插入删除,就能将bug暴露出来了.这样的bug放在昨天的话,即使有100000+个key也不一定能够暴露出来,另外一方面,节点内key的数目越少,会导致树会累计得越来越高,今天的代码里,9~10层的B+树非常常见,这会充分暴露出你节点分裂,合并,key更改时出现的种种cornel case.

第二就是,一定要手写一些测试工具,用机器来帮你检测,你自己手工来检测是非常痛苦的事情.

差不多就是这样了,现在的代码,已经经历了450000+数据的摧残,如果将节点的容量扩展到200左右的话,现在的程度相当于能够经受住>>450000 * (200 / 5)数据量的摧残,已经差不多了.

看来,逼自己一把,还是能够干一些事情的,接下来要做的事,就是优化代码,写总结了.

11月24日

花了一周时间重构了前面的三个组件的代码,代码又变得简洁了许多,其实也是没有什么办法,不重构的话,我完全无法分辨之前的代码到底干了些啥,这次重构完成了之后,可以继续后面的工作了,接下来是SM,也就是system manager组件,做完了这部分的话,这个project差不多也完成了七七八八,最后一个部分是写一个sql语句的解析器,当然,并不需要解析完整的sql语法,只有相当少的sql语法,这项工作反倒最为轻松了.

加油,我在这个project上已经拖了非常久的时间了,搞了将近两个月了,实在是不想继续拖下去,需要尽快写完了这个东西的主体部分,后续的重构可以慢慢进行,我还有别的事情要做.

11月27日

今天终于写到parser部分了,做完这个东西,一个像模像样的数据库就完成了.

不知不觉,11月份快完了,我即使认认真真写这个东西,也搞了一个多月了,真心写起蛋疼.

parser我还是用递归下降的方法来写吧,不用yacc之类的东西了,不知道到12月19日完不完得成,我突然发现,这个项目的工作量其实还是蛮大的,毕竟我还改了redbase的一些架构,写起来就更慢了.

妈蛋,主体代码完成之后,我再也不写这么大的项目了,搞到断了也不是,继续也不是.

11月30日

parser的部分架构已经搭的差不多了,以后要解析语法的话,只要在里面添加一些函数即可,Redbase的主函数也已经搭起来了,一切都已经就绪,接下里的10多天里,每天实现几个函数,每天实现几个函数,这个Project很快就可以完工了.

我突然发现,parser真是个强大的东西.总之,应该能够按时完成任务.

我发现redbase真的不复杂.它分层很清晰,ix层处理索引,sm层处理各种设定,pf层处理底层,处理好了每一层,做一个简易的sql数据库就手到擒来了.

12月1日

每日日常吐槽.心累,什么时候写得完啊.

12月3日

整个代码的思想我已经理会了,现在只需要将查询操作完成,这个项目基本上就可以完结了.

如何查询,先做什么,后做什么,这里面真是大学问,难怪查询优化是数据库里面的一个痛点难点了.

Redbase作为一个教学数据库肯定是合格的,基本上数据库的一些重要的组件都有所涉及,但是涉及得都不是很深(涉及得深了,代码又蹭蹭地涨上去了,难度也蹭蹭地涨上去了),这些组件对于理解一个数据库至关重要.没有切实写过数据库的人,估计是很难体会到数据库的一些概念的.

我想尽快写完这个项目,然后写5篇博文来简要地描述一下redbase,记录一下我两个月来的一些心得体会,第一篇应该是关于PF层,即页面管理层,第二篇关于RM层,即记录管理层,第三篇写一下实现B+树索引,第四篇写一下如何手写Redbase的parser部分,第五篇来讲一下如何实现一个简易的查询器.

这学期没有时间的话,寒假期间总有时间的.不光如此,写完之后,会有一个持续几个星期的代码重构期,总之会增加大批量的错误处理代码.不过到了那个时候的话,这个东西已经不是重点了,重构会成为休息时间的热身活动了.毕竟一直到毕业前我都不会再有什么特别大的项目了.

12月6日

代码已经基本上完成了,还有一些小的功能需要完善,不过基本上没有什么难点了,只是需要时间慢慢来磨,时间越久的话,代码的可读性和性能可以慢慢提升上来,写了这么久了,我越来越发现c++的标准库不能满足我的需求了,要先获得比较高的性能的话,必须自己实现一些轮子.你还别说,看着自己完成了一个简陋的数据库,成就感还是有的.