如何自己实现一个关系型数据库？
程序员文章站
2022-06-06 20:09:02
...
如题，最近一个同事突发奇想想要自己做一个关系型的数据库。功能可以不够完善，但是可以识别sql语句，实现增删查改。有没有什么好的资料推荐，因为我发现网上搜素到的数据库都是mysql里的一个数据库，不是整个DB，或者说是我名称用的不对？Anyway，他想纯用python实现，不知道是否有可行性？实现数据库需要掌握哪些知识？底层功能的逻辑划分是怎样的？
关系型数据库的奥义就在于实现索引、transaction、回滚，还有断电保护（
见《数据库系统概念》 最近在做的毕业设计就是做一个非常简单的关系型数据库，用Rust，目前已完成大部分模块。代码质量一般般，有兴趣就看看吧，GitHub - doyoubi/Blastoise: tiny relational database
实现了 sql parser，语义检查，生成简单的执行计划，内存池，持久化。我想基本符合题目的要求了。
不过，其实我真不推荐做这个。赞同*哥的说法，关系型数据库里面重要的内容是保证一致性和性能优化。只是简简单单造一个雏形，其实挺浪费时间，收获也不大。有时间还是应该多看资料。
不过还是贴一下做一个简单关系型数据库的资料吧。
How does a relational database work
《Database System Implementation》
https://web.stanford.edu/class/cs346/2015/
第三个是斯坦福的课程，在github上搜redbase能找到学生上传的完整代码。 推荐去读sqlite 代码。 最近一个礼拜的morning paper就讲 Database, Techiques Everyone Should Know, 引用小红书第三章
(Database) Techiques Everyone Should Know
Readings in Database Systems, 5th Edition 2016年5月25日更新
距离我写的第一个原始数据库，过了近三年
我真的自己造了个数据库 基于协程和异步IO的NoSQL数据库AsyncDB正式发布 - 林诚的文章 - 知乎专栏
-------------------------------------------------------
题主的问题，一下把我的思绪拉到了几年前
以前，我是这么写的，那时候，我还在读会计，对于编程一窍不通
以下是Python伪代码：
可以看看 LEMON语法分析生成器
这本书对应的源代码就是sqlite源码中的lemon.c, 这是个LALR(1)的parser generator, 也就4000行左右。 对外数据模型为关系型数据库，内部的实现主要分成两大类，一类是disk-based，比如mysql，postgres，一类是memory based，后者包括MemSQL，SAP HAHA，OceanBase。看题目的意思指的是前者。这里说一个disk-based的关系型数据库涉及多少东西。
上世纪70/80年代内存不大，数据不能都放在内存里，大部分数据都存在磁盘上，读数据也需要从磁盘读，然而读写磁盘太慢了，所以就在内存里做了一个buffer pool，将已经读过的数据缓存到buffer pool中，写的时候也是写到buffer pool中就返回，buffer pool的功能就是管理数据在磁盘和内存的移动。在buffer pool中数据的管理单位是page。page大小一般几十KB。一般都可以配置。如果buffer pool中没有空闲的page，就需要将某一个page提出buffer pool，如果它是dirty page，就需要flush到磁盘，这里又需要一个LRU算法。一个page包含多条记录，page的格式需要设计用来支持变长字段。如果这时宕机了，buffer pool中的数据就丢了。这就需要REDO log，将对数据的修改先写到redo log中，然后写buffer pool，然后返回给客户端，随后，buffer pool中的dirty page会被刷到数据文件中(NO FORCE)。那么重启的时候，数据就能从redo log中恢复。REDO log还没刷完就刷数据到磁盘可以加快写入速度，缺点就是恢复的时候需要回放UNDO log，回滚一些还没有提交的事务的修改。写log又分为逻辑log和物理log，还有物理逻辑log。简单说逻辑log就是记录操作，比如将某个值从1改成2.而物理log记录具体到record的位置，例如某个page的某个record的某个field，原来的值是多少，新值是多少等。逻辑log的问题是并发情况下不太好恢复成一致。物理log对于某些操作比如create table又过于琐碎，所以一般数据库都采用混合的方式。为了跟踪系统中各种操作的顺序，这就需要为log分配id，记做LSN(log sequence number)。系统中记录各种LSN，比如pageLSN, flushedLSN等等。为了加快宕机恢复速度，需要定期写checkpoint，checkpoint就是一个LSN。
以上ACID里的C和D有关。下面说A和I，即原子性和隔离性。
这两个性质通过concurrency control来保证。隔离级别有很多种，最开始有4种，从低到高read uncommitted, read committed, repeatable read, serializable。serializable就是多个事务并发执行的结果和某种顺序执行事务的结果相同。除了serializable，其他都有各种问题。比如repeatable read有幻读问题(phantom)，避免幻读需要gap lock。read committed有幻读和不可重复读问题。后来又多了一些隔离级别，比如snapshot isolation，snapshot isolation也有write skew问题。早期，并发控制协议大多是基于两阶段锁来做的(2PL)，所以早期只有前面提到的四种隔离级别，后来，又出现一类并发控制协议，统称为Timestamp Ordering，所以又多了snapshot isolation等隔离级别。关于隔离级别，可以看看这篇论文 http://research.microsoft.com/pubs/69541/tr-95-51.pdf。2PL需要处理deadlock的问题。
Timestamp Ordering大体的思想就是认为事务之间冲突不大，不需要加锁，只在commit的时候check是否有冲突。属于一种乐观锁。
Timestamp Ordering具体来说包括多种，最常见的MVCC就是这类，还有一类叫做OCC(optimistic concurrency control)。MVCC就是对于事务的每次更新都产生新的版本，使用时间戳做版本号。读的时候可以读指定版本或者读最新的版本。几乎主流数据库都支持MVCC，因为MVCC读写互相不阻塞，读性能高。MySQL的回滚段就是用来保存老的版本。MVCC需要有后台线程来做不再需要的版本的回收工作。Postgres的vacuum就是做这事的。OCC和MVCC的区别是，OCC协议中，事务的修改保存在私有空间(比如客户端)，commit的时候再去检测冲突，通常的做法是事务开始时看一下自己要修改的数据的最后一次修改的时间戳，提交的时候去check是否这个时间戳变大了，如果是，说明被别人改过了，冲突。冲突后可以回滚或者重试。
上面这些搞定了就实现了数据库的核心，然后为了性能，需要index，通常有两种，一种支持顺序扫描B+Tree,还有一种是Hash Index。单条读适合用Hash Index,O(1)时间复杂度，顺序扫描只适合用B+Tree，O(logN)复杂度。然后，有些查询只需要扫描索引就能得到结果，有些查询直接扫描数据表就能得到结果，有些查询可以走二级索引，通过二级索引找到数据表然后得到结果。。具体用哪种方式就是优化器的事了。
再外围一些，关系型数据库自然需要支持SQL了，由SQL变成最后可以执行的物理执行计划中间又有很多步，首先SQL通过词法语法分析生成抽象语法树，然后planner基于这棵树生成逻辑执行计划，逻辑执行计划的生成通常涉及到等价谓词重写，子查询消除等逻辑层面的优化技术，优化的目的当然是性能。比如等价谓词重写，用大于小于谓词消除like，between .. and..等不能利用索引的谓词。下一步是逻辑执行计划生成物理执行计划，物理执行计划树每个节点是一个operator，operator的执行就是实实在在的操作，比如扫表的operator，filter opertor。一个逻辑执行计划通常可以有多个物理执行对应，选择哪个就涉及到物理执行计划优化，这里涉及到经典的cost model，综合考虑内存,CPU, I/O,网络等。最典型的，三表join，从左到右还是右到左，使用hash join，还是sort merge join等。关于查询优化器可以参考这本书 数据库查询优化器的艺术：原理解析与SQL性能优化
可以看出，要实现一个disk-based关系型数据库系统非常复杂，想看代码的话直接看postgres吧
先写这些，以后慢慢补充。。。 java的话，有derby可以参考。 一个成熟的数据库的实现难度不低于实现一个成熟的操作系统。练手可以拿UWisconsin Madison的教学用MiniBase试试。 ^_^先写一个并发控制子系统。里面要提供各种各样的闩锁。包括具有不同相容性矩阵的，有优先队列或者没有的，能指数后退或者不能的，全局可追踪的或者不可追踪的，等等等等。
然后写一个存储管理子系统。在这里你可以决定你的数据库的外存布局。比如一个表可不可以分开几个文件存，有没有区的概念，有没有段的概念，有没有表空间的概念，它们之中谁是定长的，谁是可变长的，谁是空间申请单位，谁是空间调度单位。决定好了开始设计页区段表空间格式，它们的描述符格式，然后用页头，页记录，页尾有的没的串一起。设计好了开始决定这个子系统有哪些内存对象，至少要有一个存储管理器用来初始化，分配或者调度存储单元，至少还要提供一堆方法来决定怎么把二进制数据变成有意义的数据，比如读一个ushort, 写一个uint64等等。
之后就要开始写一个缓冲区管理子系统(假设你做的不是一个内存数据库)。先弄明白什么是一个block，一个page, 一个frame。这些都是你的类。然后写一个缓冲池，再写一个缓冲区管理器。缓冲池规定数据在内存上的布局，缓冲区管理器就是这个系统的接口了，可以回应一个页的申请，并实现你最心仪的页替换策略。
再之后要写一个日志系统。先想好你是要用shadow page日志啊，还是ARIES算法日志啊。假设用后者，于是你就失去了强制写，并采用偷帧的技术。这样你要设计redo日志的格式，并使你的日志记录种类可扩展，因为不一定什么时候你就会需要一种新的日志记录。如果想让你的系统更稳健，看看需不需要组日志(一组日志记录要么都重做要么都不重做)。如果想让你的系统更高效，看看需不需要mvcc。要的话还得再加入undo日志，并设计格式。下面你要设计日志记录粒度。全物理日志？全逻辑日志？物理逻辑日志。总之，逻辑的成分越多，系统设计越复杂(比如糟糕的部分写怎么处理)。最后跟存储管理系统要个地方物化日志，再管缓冲区管理系统要个地方用来调度日志页。
接下来要写一个锁系统。先想好你的系统是表级锁还是页级锁还是行级锁。前两个最自然，直接用fix number什么的就搞定，最后一个你要有用来表示行锁的额外数据结构。每个行一个锁实例？每个页共用一坨锁实例？之后去这个锁表，用来统一申请释放锁。最后再决定如何解决死锁，超时抛出异常？依赖图分析？
再接下来要写一个事务子系统。它无非就是提供了一些方法确保各种操作正确地使用了二阶段锁，正确地写了日志，正确地回滚。但是这个系统的架构由"各种操作"的多样性决定。相比堆文件，对b+树组织的记录文件中记录的增删改查就要极大复杂化日志写入过程。相比定长记录文件，对可变长记录的增删改查又是another story。
还有元数据管理子系统，记录(索引)子系统。以上这些组成了一个存储引擎。题主还想要的额外的东西分别是: SQL lexer, SQL parser, SQL planner, SQL optimizer。以上又构成了一个SQL compiler。 最后再来个Server/Client Module 用来控制权限，提供API，估计就差不多了。
至于后面那些组件的概要，等我找来时间再写吧。
(补充一下，用Python写，第一个子系统就是个问题，你顶多能用acquire_lock() 找出来一个没有队列(似乎有个wait参数可以指定要不要线程等待，所以也许是有队列的，细节我忘了，囧)的自旋锁。但是数据库要求自旋次数可自定义，还要有优先队列来让线程睡眠。另外，凡是有GC的语言，缓冲区都不受你控制。因为页被踢出后，并不代表它被析构，万一代码没写好，GC一直以为它有用，不就成内存泄漏了。)
回复内容：
都答偏了啊。关系型数据库的奥义就在于实现索引、transaction、回滚，还有断电保护（
见《数据库系统概念》 最近在做的毕业设计就是做一个非常简单的关系型数据库，用Rust，目前已完成大部分模块。代码质量一般般，有兴趣就看看吧，GitHub - doyoubi/Blastoise: tiny relational database
实现了 sql parser，语义检查，生成简单的执行计划，内存池，持久化。我想基本符合题目的要求了。
不过，其实我真不推荐做这个。赞同*哥的说法，关系型数据库里面重要的内容是保证一致性和性能优化。只是简简单单造一个雏形，其实挺浪费时间，收获也不大。有时间还是应该多看资料。
不过还是贴一下做一个简单关系型数据库的资料吧。
How does a relational database work
《Database System Implementation》
https://web.stanford.edu/class/cs346/2015/
第三个是斯坦福的课程，在github上搜redbase能找到学生上传的完整代码。 推荐去读sqlite 代码。 最近一个礼拜的morning paper就讲 Database, Techiques Everyone Should Know, 引用小红书第三章
(Database) Techiques Everyone Should Know
Readings in Database Systems, 5th Edition 2016年5月25日更新
距离我写的第一个原始数据库，过了近三年
我真的自己造了个数据库 基于协程和异步IO的NoSQL数据库AsyncDB正式发布 - 林诚的文章 - 知乎专栏
-------------------------------------------------------
题主的问题，一下把我的思绪拉到了几年前
以前，我是这么写的，那时候，我还在读会计，对于编程一窍不通
以下是Python伪代码：
import pickle
my_db = {}
db_file = open('db')
pickle.dump(my_db, db_file)
pickle.load(my_db, db_file)
可以看看 LEMON语法分析生成器
这本书对应的源代码就是sqlite源码中的lemon.c, 这是个LALR(1)的parser generator, 也就4000行左右。 对外数据模型为关系型数据库，内部的实现主要分成两大类，一类是disk-based，比如mysql，postgres，一类是memory based，后者包括MemSQL，SAP HAHA，OceanBase。看题目的意思指的是前者。这里说一个disk-based的关系型数据库涉及多少东西。
上世纪70/80年代内存不大，数据不能都放在内存里，大部分数据都存在磁盘上，读数据也需要从磁盘读，然而读写磁盘太慢了，所以就在内存里做了一个buffer pool，将已经读过的数据缓存到buffer pool中，写的时候也是写到buffer pool中就返回，buffer pool的功能就是管理数据在磁盘和内存的移动。在buffer pool中数据的管理单位是page。page大小一般几十KB。一般都可以配置。如果buffer pool中没有空闲的page，就需要将某一个page提出buffer pool，如果它是dirty page，就需要flush到磁盘，这里又需要一个LRU算法。一个page包含多条记录，page的格式需要设计用来支持变长字段。如果这时宕机了，buffer pool中的数据就丢了。这就需要REDO log，将对数据的修改先写到redo log中，然后写buffer pool，然后返回给客户端，随后，buffer pool中的dirty page会被刷到数据文件中(NO FORCE)。那么重启的时候，数据就能从redo log中恢复。REDO log还没刷完就刷数据到磁盘可以加快写入速度，缺点就是恢复的时候需要回放UNDO log，回滚一些还没有提交的事务的修改。写log又分为逻辑log和物理log，还有物理逻辑log。简单说逻辑log就是记录操作，比如将某个值从1改成2.而物理log记录具体到record的位置，例如某个page的某个record的某个field，原来的值是多少，新值是多少等。逻辑log的问题是并发情况下不太好恢复成一致。物理log对于某些操作比如create table又过于琐碎，所以一般数据库都采用混合的方式。为了跟踪系统中各种操作的顺序，这就需要为log分配id，记做LSN(log sequence number)。系统中记录各种LSN，比如pageLSN, flushedLSN等等。为了加快宕机恢复速度，需要定期写checkpoint，checkpoint就是一个LSN。
以上ACID里的C和D有关。下面说A和I，即原子性和隔离性。
这两个性质通过concurrency control来保证。隔离级别有很多种，最开始有4种，从低到高read uncommitted, read committed, repeatable read, serializable。serializable就是多个事务并发执行的结果和某种顺序执行事务的结果相同。除了serializable，其他都有各种问题。比如repeatable read有幻读问题(phantom)，避免幻读需要gap lock。read committed有幻读和不可重复读问题。后来又多了一些隔离级别，比如snapshot isolation，snapshot isolation也有write skew问题。早期，并发控制协议大多是基于两阶段锁来做的(2PL)，所以早期只有前面提到的四种隔离级别，后来，又出现一类并发控制协议，统称为Timestamp Ordering，所以又多了snapshot isolation等隔离级别。关于隔离级别，可以看看这篇论文 http://research.microsoft.com/pubs/69541/tr-95-51.pdf。2PL需要处理deadlock的问题。
Timestamp Ordering大体的思想就是认为事务之间冲突不大，不需要加锁，只在commit的时候check是否有冲突。属于一种乐观锁。
Timestamp Ordering具体来说包括多种，最常见的MVCC就是这类，还有一类叫做OCC(optimistic concurrency control)。MVCC就是对于事务的每次更新都产生新的版本，使用时间戳做版本号。读的时候可以读指定版本或者读最新的版本。几乎主流数据库都支持MVCC，因为MVCC读写互相不阻塞，读性能高。MySQL的回滚段就是用来保存老的版本。MVCC需要有后台线程来做不再需要的版本的回收工作。Postgres的vacuum就是做这事的。OCC和MVCC的区别是，OCC协议中，事务的修改保存在私有空间(比如客户端)，commit的时候再去检测冲突，通常的做法是事务开始时看一下自己要修改的数据的最后一次修改的时间戳，提交的时候去check是否这个时间戳变大了，如果是，说明被别人改过了，冲突。冲突后可以回滚或者重试。
上面这些搞定了就实现了数据库的核心，然后为了性能，需要index，通常有两种，一种支持顺序扫描B+Tree,还有一种是Hash Index。单条读适合用Hash Index,O(1)时间复杂度，顺序扫描只适合用B+Tree，O(logN)复杂度。然后，有些查询只需要扫描索引就能得到结果，有些查询直接扫描数据表就能得到结果，有些查询可以走二级索引，通过二级索引找到数据表然后得到结果。。具体用哪种方式就是优化器的事了。
再外围一些，关系型数据库自然需要支持SQL了，由SQL变成最后可以执行的物理执行计划中间又有很多步，首先SQL通过词法语法分析生成抽象语法树，然后planner基于这棵树生成逻辑执行计划，逻辑执行计划的生成通常涉及到等价谓词重写，子查询消除等逻辑层面的优化技术，优化的目的当然是性能。比如等价谓词重写，用大于小于谓词消除like，between .. and..等不能利用索引的谓词。下一步是逻辑执行计划生成物理执行计划，物理执行计划树每个节点是一个operator，operator的执行就是实实在在的操作，比如扫表的operator，filter opertor。一个逻辑执行计划通常可以有多个物理执行对应，选择哪个就涉及到物理执行计划优化，这里涉及到经典的cost model，综合考虑内存,CPU, I/O,网络等。最典型的，三表join，从左到右还是右到左，使用hash join，还是sort merge join等。关于查询优化器可以参考这本书 数据库查询优化器的艺术：原理解析与SQL性能优化
可以看出，要实现一个disk-based关系型数据库系统非常复杂，想看代码的话直接看postgres吧
先写这些，以后慢慢补充。。。 java的话，有derby可以参考。 一个成熟的数据库的实现难度不低于实现一个成熟的操作系统。练手可以拿UWisconsin Madison的教学用MiniBase试试。 ^_^先写一个并发控制子系统。里面要提供各种各样的闩锁。包括具有不同相容性矩阵的，有优先队列或者没有的，能指数后退或者不能的，全局可追踪的或者不可追踪的，等等等等。
然后写一个存储管理子系统。在这里你可以决定你的数据库的外存布局。比如一个表可不可以分开几个文件存，有没有区的概念，有没有段的概念，有没有表空间的概念，它们之中谁是定长的，谁是可变长的，谁是空间申请单位，谁是空间调度单位。决定好了开始设计页区段表空间格式，它们的描述符格式，然后用页头，页记录，页尾有的没的串一起。设计好了开始决定这个子系统有哪些内存对象，至少要有一个存储管理器用来初始化，分配或者调度存储单元，至少还要提供一堆方法来决定怎么把二进制数据变成有意义的数据，比如读一个ushort, 写一个uint64等等。
之后就要开始写一个缓冲区管理子系统(假设你做的不是一个内存数据库)。先弄明白什么是一个block，一个page, 一个frame。这些都是你的类。然后写一个缓冲池，再写一个缓冲区管理器。缓冲池规定数据在内存上的布局，缓冲区管理器就是这个系统的接口了，可以回应一个页的申请，并实现你最心仪的页替换策略。
再之后要写一个日志系统。先想好你是要用shadow page日志啊，还是ARIES算法日志啊。假设用后者，于是你就失去了强制写，并采用偷帧的技术。这样你要设计redo日志的格式，并使你的日志记录种类可扩展，因为不一定什么时候你就会需要一种新的日志记录。如果想让你的系统更稳健，看看需不需要组日志(一组日志记录要么都重做要么都不重做)。如果想让你的系统更高效，看看需不需要mvcc。要的话还得再加入undo日志，并设计格式。下面你要设计日志记录粒度。全物理日志？全逻辑日志？物理逻辑日志。总之，逻辑的成分越多，系统设计越复杂(比如糟糕的部分写怎么处理)。最后跟存储管理系统要个地方物化日志，再管缓冲区管理系统要个地方用来调度日志页。
接下来要写一个锁系统。先想好你的系统是表级锁还是页级锁还是行级锁。前两个最自然，直接用fix number什么的就搞定，最后一个你要有用来表示行锁的额外数据结构。每个行一个锁实例？每个页共用一坨锁实例？之后去这个锁表，用来统一申请释放锁。最后再决定如何解决死锁，超时抛出异常？依赖图分析？
再接下来要写一个事务子系统。它无非就是提供了一些方法确保各种操作正确地使用了二阶段锁，正确地写了日志，正确地回滚。但是这个系统的架构由"各种操作"的多样性决定。相比堆文件，对b+树组织的记录文件中记录的增删改查就要极大复杂化日志写入过程。相比定长记录文件，对可变长记录的增删改查又是another story。
还有元数据管理子系统，记录(索引)子系统。以上这些组成了一个存储引擎。题主还想要的额外的东西分别是: SQL lexer, SQL parser, SQL planner, SQL optimizer。以上又构成了一个SQL compiler。 最后再来个Server/Client Module 用来控制权限，提供API，估计就差不多了。
至于后面那些组件的概要，等我找来时间再写吧。
(补充一下，用Python写，第一个子系统就是个问题，你顶多能用acquire_lock() 找出来一个没有队列(似乎有个wait参数可以指定要不要线程等待，所以也许是有队列的，细节我忘了，囧)的自旋锁。但是数据库要求自旋次数可自定义，还要有优先队列来让线程睡眠。另外，凡是有GC的语言，缓冲区都不受你控制。因为页被踢出后，并不代表它被析构，万一代码没写好，GC一直以为它有用，不就成内存泄漏了。)
声明：本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系admin@php.cn核实处理。
相关文章
相关视频