关于CauchyDB
这次我们介绍的主角,是我最近开始编写的CauchyDB,鉴于我还没有完成它的开发(因为考试周的原因……),所以暂时没有放到GitHub上。这个系列的文章,主要就CauchyDB的设计架构进行一系列的讨论,如有不足之处,欢迎大家指出,谢谢。
前言
硬盘数据库与内存数据库
这两种数据库看起来差别很大,不过实际上差距已经越来越小,硬盘数据库也有强有力的内存Buffer,内存数据库也有各种可持久化手段,CauchyDB基于硬盘数据库的理念开发,并且提供精简高效的Buffer来提高效率。
Buffer的读策略
由于是硬盘数据库,Buffer采用延迟载入的手段,在每一次载入时,可以读一整个Block(这样会提高效率,因为硬盘的基本读写单位就是Block),获取数据时,一定从Buffer获取,如果Buffer没有就载入Buffer,如果Buffer满了,那就采取Pop的策略(这里可以有很多算法,比如维护一个堆,或者采取频率统计的方法管理Buffer,当然也可以做成可扩展性的维护策略,有利于后期修改。
Buffer的写策略
Buffer的写策略主要有两种,写透(每次都同步到硬盘)和贪婪(定时同步到硬盘),贪婪策略主要用于对可持久化要求不高的内存数据库,当然硬盘数据库也可以使用,同时更可以配合日志提高稳健性,写透策略效率会略低,不过对于高读少写的数据库来说,还是可以接受的。
数据抽象
抽象是Programming的essence,有了良好的数据抽象不但利于编码,更利于维护,还能提高效率。我认为,架构是软件的灵魂,设计一个好的架构远比写出大量代码重要的多。首先实现代码功能是不可取的,这样在后续的开发过程中只能举步维艰。
软件开发,就像是攻城略地,写出功能如同攻下一城,通过测试如同守下一城,患得患失只会让人丧失未来的机会,真正的军事战略家应在站在全局的层面,把握宏观战略,而软件的架构则同理。
CauchyDB的数据抽象
第一层抽象 硬盘文件模型 CauchyFile
需求
:无
实现
:利用cstdio实现磁盘IO操作
提供
:二进制磁盘IO读写类
对磁盘的文件操作往往是令人恼火的,所以封装一系列的C文件IO成为一个C++类是很有必要的,这样让顶层的程序无需关心磁盘操作的细节,只需调用提供的API即可。
第二层抽象 数据区块模型 Block
需求
:二进制磁盘IO读写类,内存数组
实现
:Buffer自动载入、控制,磁盘自动回写
提供
:以Block为载体的自动缓存的磁盘IO数据对象
这一层抽象是基础,通过将硬盘文件和内存Buffer的数据块公有抽象出一种Block供上层代码实现,而不用关心内存Buffer和磁盘IO的写入,这会让之后的代码更加关注数据操作本身,而不用关注数据的来源、位置。
第三层抽象 二进制段模型 BitPtr
需求
:以Block为载体的自动缓存的磁盘IO数据对象,二进制数组
实现
:操作分发
提供
:二进制数据块指针对象
这一层抽象是讲数据库存储的数据和临时的二进制数据统一为一个BitPtr Class,这层抽象可能有些冗余,但是统一的接口将为接下来的编码工作提供很大的便利。
第四层抽象 B+TREE节点 NodeBitPtr (举例)
需求
:二进制数据块指针对象
实现
:B+Tree节点二进制数据含义的解析
提供
:B+Tree节点的读写修改操作
这一层的抽象继承自第三层,因为节点本质上也是二进制数据,但是节点的二进制数据有着独特的含义,所以可以将其包装来提供特有的API,同时不用关心二进制数据的存放方式。
第五层抽象 B+TREE索引 BPlusTree(举例)
需求
:B+Tree节点的读写修改操作
实现
:B+Tree 的增查删改
提供
:基于硬盘和内存Buffer的B+Tree
待续
第六层抽象 SQL解释器
需求
:B+Tree index,data,SQL
实现
:语义分析和查询执行
提供
:SQL执行接口
待续
抽象的意义
抽象的意义何在?相比大家已经看到了,抽象的意义在于让人不用关心实现而关心接口,这是计算机科学之所以发展到今天的精髓之一,所以实现好抽象是CS学生的基本功,一定要多抽象才能提升自己的代码实力。