[数据库架构设计]关系型数据库的内存数据模型(CauchyDB 系列I)

关于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学生的基本功，一定要多抽象才能提升自己的代码实力。