RFDBs 一款轻量级的文件型Key-Value大容量存储的数据库

RFDBs是一款文件型的Kv数据库它的应用场景主要被集中在我们的桌面客户端程序的中 一般桌面客户端应用数据库这块基本是自己设计自己做 用第三方？此大容量值意为存很大的数据它会比较快 而不是小数据块

回到正题我并不是很欣赏这个Kv数据库的设计 虽然它是我亲手研发的 一种不是令我足够满意的方案 当然既然在我们客户端的基础设施中我已经添加进了对此数据库的支持 

不过在这里需要注明在blog提出的文件数据库不会做任何的日志库俗称备库（假设如果程序挂掉时 而恰好这个数据库正在构建索引表 那么就具备崩库的风险）你可以手动添加日志库提供灾难恢复的功能 值得一提所有的文件型数据库都有这个毛病

上图是我一月分新提出的一种Kv数据库存储结构（QKvDB）这个工程由于种种原因被延期 即便是现在我真的没有

时间去研发这个东西 从昨天下午开始全职研究与弄流媒体领域方面的东西（这个门槛有点高 搞起有点累 但很有意思 很有趣）

上图是本blog的重点RFDBs的存储设计图 从上图中你可以看出与QKvDB差距很大 它们之间存储结构体系从根本

设计上是相悖的

虽然从存储单元都是以块帧的概念 但双方的关注点与侧重点差异特别大 

RFDBs在出发设计点上是在文件中构建一个映射表、RFDBs存储结构头 从映射表中检索相对于数据库中的资源数据 看上去似乎并没有任何问题 但它却引发了一个严重的问题 它提高了重复移动内存提高了性能与资源成本

一旦以映射表作为关键结构 那么不可避免当用户调用“添加、删除、更新”时 你必须对整个映射表进行一次重构然后放入文件中 这很类似与MSSQL重建数据库索引的过程 但这就是它的弱点 也是我在设计这个结构时所犯下的错误

那么既然提到了“添加、删除、更新”数据 那么显然很有必要去关注它是否可以重复空闲内容空间 它是可以复用空闲容量空间的 同时值得注意的是它可能无法完全复用内容空间 这与CLR上的GC子系统在出现“托管内存空洞”的问题时的策略是基本相同的 可以向这块空洞注入数据 但无法保证能够填充满 否则它会采取另外的策略

这块无法填充的存储空洞 它可能是几个字节或者几个千字节 完全取决你单次存入RFDBs的二进制缓冲区数据大小 但可以确定的是如果无法复用则会扩充文件的容量存入

但自增从本质上是一种节约存储的方式但有时它并没有想象中的那么美丽 它提高了性能成本 提高了扩增文件容量所需要花费的时钟周期

而QKvDB则吸取了相关教训而提供出的一种Kv文件存储设计 不在考虑在文件中建立映射表 只是单纯的定长存储结构头 用块帧存储连续的数据 即上一个块帧的结尾处是下一个块帧的开始

对于删除不再是如RFDBs一般需要抹除映射表并且重构 它只需要单纯设置废弃态 对于添加那么检索所有废弃的块帧

中是否具备与当然所需要存储整块块帧的大小 如果空闲容量大于存储大小 则检索加上存储大小与空白块帧的大小 那么满足就可以填充空洞 否则扩充 但必须保证块帧之间的连续性 否则你可能无法寻址内容数据

这是一个RFDBs的简单的应用示例程序 它的Bug有点多 但功能是实在的（你可以右键ListView打开右键菜单 这里示例功能会多一些）

RFDBs源代码级示例代码的获取资源地址：http://pan.baidu.com/s/1i4Ozqbb