百科问答小站 logo
百科问答小站 font logo



怎么实现一个简单的数据库系统? 第1页

  

user avatar   alchemystar 网友的相关建议: 
      

自己动手写SQL执行引擎

前言

在阅读了大量关于数据库的资料后,笔者情不自禁产生了一个造数据库轮子的想法。来验证一下自己对于数据库底层原理的掌握是否牢靠。在笔者的github中给这个database起名为Freedom。

整体结构

既然造轮子,那当然得从前端的网络协议交互到后端的文件存储全部给撸一遍。下面是Freedom实现的整体结构,里面包含了实现的大致模块:


最终存储结构当然是使用经典的B+树结构。当然在B+树和文件系统block块之间的转换则通过Buffer(Page) Manager来进行。当然了,为了完成事务,还必须要用WAL协议,其通过Log Manager来操作。
Freedom采用的是索引组织表,通过DruidSQL Parse来将sql翻译为对应的索引操作符进而进行对应的语义操作。

MySQL Protocol结构

client/server之间的交互采用的是MySQL协议,这样很容易就可以和mysql client以及jdbc进行交互了。

query packet

mysql通过3byte的定长包头去进行分包,进而解决tcp流的读取问题。再通过一个sequenceId来再应用层判断packet是否连续。


result set packet

mysql协议部分最复杂的内容是其对于result set的读取,在NIO的方式下加重了复杂性。
Freedom通过设置一系列的读取状态可以比较好的在Netty框架下解决这一问题。


row packet

还有一个较简单的是对row格式进行读取,如上图所示,只需要按部就班的解析即可。


由于协议解析部分较为简单,在这里就不再赘述。

SQL Parse

Freedom采用成熟好用的Druid SQL Parse作为解析器。事实上,解析sql就是将用文本表示
的sql语义表示为一系列操作符(这里限于篇幅原因,仅仅给出select中where过滤的原理)。

对where的处理

例如where后面的谓词就可以表示为一系列的以树状结构组织的SQL表达式,如下图所示:


当access层通过游标提供一系列row后,就可以通过这个树状表达式来过滤出符合where要求的数据。Druid采用了Parse中常用的visitor很方便的处理上面的表达式计算操作。

对join的处理

对join最简单处理方案就是对两张表进行笛卡尔积,然后通过上面的where condition进行过滤,如下图所示:


Freedom对于缩小笛卡尔积的处理

由于Freedom采用的是B+树作为底层存储结构,所以可以通过where谓词来界定B+树scan(搜索)的范围(也即最大搜索key和最小搜索key在B+树种中的位置)。考虑sql

       select a.*,b.* from t_archer as a join t_rider as b where a.id>=3 and a.id<=11 b.id and b.id>=19 b.id<=31     

那么就可以界定出在id这个索引上,a的scan范围为[3,11],如下图所示:


b的scan范围为[19,31],如下图所示(假设两张表数据一样,便于绘图):


scan少了从原来的15*15(一共15个元素)次循环减少到4*4次循环,即循环次数减少到7.1%

当然如果存在join condition的话,那么Freedom在底层cursor递归处理的过程中会预先过滤掉一部分数据,进一步减少上层的过滤。

B+Tree的磁盘结构

leaf磁盘结构

Freedom的B+Tree是存储到磁盘里的。考虑到存储的限制以及不定长的key值,所以会变得非常复杂。Freedom以page为单位来和磁盘进行交互。叶子节点和非叶子节点都由page承载并刷入磁盘。结构如下所示:


一个元组(tuple/item)在一个page中分为定长的ItemPointer和不定长的Item两部分。
其中ItemPointer里面存储了对应item的起始偏移和长度。同时ItemPointer和Item如图所示是向着中心方向进行伸张,这种结构很有效的组织了非定长Item。

leaf和node节点在Page中的不同

虽然leaf和node在page中组织结构一致,但其item包含的项确有区别。由于Freedom采用的是索引组织表,所以对于leaf在聚簇索引(clusterIndex)和二级索引(secondaryIndex)中对item的表示也有区别,如下图所示:


其中在二级索引搜索时通过secondaryIndex通过index-key找到对应的clusterId,再通过
clusterId在clusterIndex中找到对应的row记录。
由于要落盘,所以Freedom在node节点中的item里面写入了index-key对应的pageno,
这样就可以容易的从磁盘恢复所有的索引结构了。

B+Tree在文件中的组织

有了Page结构,我们就可以将数据承载在一个个page大小的内存里面,同时还可以将page刷新到对应的文件里。有了node.item中的pageno,我们就可以较容易的进行文件和内存结构之间的互相映射了。
B+树在磁盘文件中的组织如下图所示:


B+树在内存中相对应的映射结构如下图所示:


文件page和内存page中的内容基本是一致的,除了一些内存page中特有的字段,例如dirty等。

每个索引一个B+树

在Freedom中,每个索引都是一颗B+树,对记录的插入和修改都要对所有的B+树进行操作。

B+Tree的测试

笔者通过一系列测试case,例如随机变长记录对B+树进行插入并落盘,修复了其中若干个非常诡异的corner case。

B+Tree的todo

笔者这里只是完成了最简单的B+树结构,没有给其添加并发修改的锁机制,也没有在B+树做操作的时候记录log来保证B+树在宕机等灾难性情况下的一致性,所以就算完成了这么多的工作量,距离一个高并发高可用的bptree还有非常大的距离。

Meta Data

table的元信息由create table所创建。创建之后会将元信息落盘,以便Freedom在重启的时候加载表信息。每张表的元信息只占用一页的空间,依旧复用page结构,主要保存的是聚簇索引和二级索引的信息。元信息对应的Item如下图所示:


如果想让mybatis可以自动生成关于Freedom的代码,还需实现一些特定的sql来展现Freedom的元信息。这个在笔者另一个项目rider中有这样的实现。原理如下图所示:


实现了上述4类SQL之后,mybatis-generator就可以通过jdbc从Freedom获取元信息进而自动生成代码了。

事务支持

由于当前Freedom并没有保证并发,所以对于事务的支持只做了最简单的WAL协议。通过记录redo/undolog从而实现原子性。

redo/undo log协议格式

Freedom在每做一个修改操作时,都会生成一条日志,其中记录了修改前(undo)和修改后(redo)的行信息,redo用来回滚,redo用来宕机recover。结构如下图所示:


WAL协议

WAL协议很好理解,就是在事务commit前将当前事务中所产生的的所有log记录刷入磁盘。
Freedom自然也做了这个操作,使得可以在宕机后通过log恢复出所有的数据。


回滚的实现

由于日志中记录了undo,所以对于一个事务的回滚直接通过日志进行undo即可。如下图所示:


宕机恢复

Freedom如果在page全部刷盘之后关机,则可以由通过加载page的方式获取原来的数据。
但如果突然宕机,例如kill -9之后,则可以通过WAL协议中记录的redo/undo log来重新
恢复所有的数据。由于时间和精力所限,笔者并没有实现基于LSN的检查点机制。

Freedom运行

       git clone https://github.com/alchemystar/Freedom.git // 并没有做打包部署的工作,所以最简单的方法是在java编辑器里面 run alchemystar.freedom.engine.server.main     

以下是笔者实际运行Freedom的例子:


join查询


delete回滚


Freedom todo

Freedom还有很多工作没有完成,例如有层次的锁机制和MVCC等,由于工作忙起来就耽搁了。
于是笔者就看了看MySQL源码的实现理解了一下锁和MVCC实现原理,并写了两篇博客。比起
自己动手撸实在是轻松太多了^_^。

MVCC

my.oschina.net/alchemys

二阶段锁

my.oschina.net/alchemys

尾声

在造轮子的过程中一开始是非常有激情非常快乐的。但随着系统越来越庞大,复杂性越来越高,进度就会越来越慢,还时不时要推翻自己原来的设想并重新设计,然后再协同修改关联的所有代码,就如同泥沼,越陷越深。至此,笔者才领悟了软件工程最重要的其实是控制复杂度!始终保持简洁的接口和优雅的设计是实现一个大型系统的必要条件。

收获与遗憾

这次造轮子的过程基本满足了笔者的初衷,通过写一个数据库来学习数据库。不仅仅是加深了理解,最重要的是笔者在写的过程中终于明白了数据库为什么要这么设计,为什么不那样设计,仅仅对书本的阅读可能并不会有这些思考与领悟。
当然,还是有很多遗憾的,Freedom并没有实现锁机制和MVCC。由于只能在工作闲暇时间写,所以断断续续写了一两个月,工作一忙就将这个项目闲置了。现在将Freedom的设计写出来,希望大家能有所收获。

欢迎大家关注我公众号,里面有各种原创干货

想要学习怎么写数据库?那当然是看下面这本:

github链接

github.com/alchemystar/

码云链接

gitee.com/alchemystar/F


user avatar   wang-ting-zheng-45 网友的相关建议: 
      

我跟你讲一下,我们这边有些人结婚的一个情况。


女方家开出几百万的,都有。

什么意思呢?我给你捋一下

女方父母,站在一个角度

我给我女儿,准备个几百万的资产

你男方,也得按照这个规格上下浮动。

这笔钱,双方父母都不能染指。

必须给到他们小两口。


其实,这就是我们这边结婚的一个习俗。

有些女方家的家长带急眼的。

听亲戚说的是,男方来了一笔不小的钱。

女孩子她爹觉得,这是在侮辱她。

反手,准备了一笔更大的钱,给女儿带过去。


最后双方父母怎样了,我们不知道。

但是那小两口开心的不要不要的。


在我们这边,结婚,有些家庭不好的女孩子

不敢随便收彩礼的。

一般是有两种情况。

男方来多少,女方来多少,最终交给小两口

男方多少,女方加点还回去,最终给到小两口。

如果是第一种情况,女方家真就不敢随便收人彩礼。

这是双方父母的一个博弈过程。


不过,我觉得有个传统非常好。

父母对父母,不会波及小两口。

两种方案下,只要小两口想在一起,父母基本都不会阻拦。

除非是人品,名声,家境,实在太差的情况。

这种情况,谁愿意自己孩子弄过去?


偶尔也会出现那种,父母克扣彩礼的情况。

但是非常的少

所以,一旦出现这种情况,除非女方父母断绝所有亲戚来往

不然,名声会变得非常臭。

严重点的,还会上升到家族名誉,波及其他亲戚的名声。

就属于那种十里八乡成名人的地步。

谁都知道,女方他爹窝囊,靠卖女儿换生存。

尤其是哪彩礼给弟弟做彩礼的情况。

这样的弟弟,除非娶一个不知情的女孩子。

不然,大家都不愿意让自己女儿嫁给他

因为,很丢人。

而且,在我们的认知里,就属于承担不起家庭责任,不配结婚的那种。

一个男的,连讨老婆,都需要用姐姐的钱。

在大家眼里,就等同于废物。

而我们那边,男人的名声,又等于家庭的名声。

所以,父母克扣彩礼,是一件非常严重的事情。

听说,还有人因此被开除祖籍的。(这个是听说的,我没办法做考证)

所以,在我们这边,家里的钱都是由女人管着的。

我们这边结婚,虽然不要彩礼,但是你得真有相匹配的财产。

至于所谓的借,那不存在的,女方家一般不稀罕。

尤其是女方家得知男方家借钱来装阔,那我跟你讲

可能会打架。。。。。


题主你爸爸要是按照这种逻辑,提出这种要求

我认为非常合理。

因为,钱不在他手里

别说,58万,就是580万,都是合情合理的

因为,你爸爸给你准备的底气,就有这么足

我是不能理解,为什么会有人骂你耶。。。。


婚姻本身就是一个双方家庭先博弈,再握手言和的过程。

如果男方他妈一味的要你懂事。

本身就很扯的。



我是狗子

希望你幸福




  

相关话题

  怎样才能写出高质量的SQL语句? 
  如何理解关系型数据库的常见设计范式? 
  SQLite 的读写效率很高,有哪些使用其他数据库的理由? 
  如何看待王垠对数据库的理解? 
  数据库设计时的一些细节的东西如何处理? 
  有Execl了要数据库干啥? 
  假如有人把支付宝所有存储服务器炸了(物理炸),大众在支付宝里的钱是不是就都没有了呢? 
  SQLite 的读写效率很高,有哪些使用其他数据库的理由? 
  一直很热闹的数据库领域,有哪些事情让你感觉眼前一亮? 
  怎样理解分析王垠文章《SQL,NoSQL 以及数据库的实质》的观点? 

前一个讨论
读博导师和学校哪个重要呢?
下一个讨论
哈工大社会计算与信息检索实验室(SCIR)实力怎么样,值得去吗?





© 2024-12-22 - tinynew.org. All Rights Reserved.
© 2024-12-22 - tinynew.org. 保留所有权利