从零实现一个轻量级数据库——MYDB的核心架构解析

1. 为什么需要自己实现数据库第一次接触数据库时很多人都会有这样的疑问市面上已经有MySQL、PostgreSQL这些成熟产品为什么还要从零开始造轮子这个问题我也思考了很久。直到去年做电商系统时遇到一个特殊场景需要处理海量商品标签数据每条记录都包含动态变化的JSON字段。现有数据库要么性能跟不上要么扩展成本太高这才让我下定决心自己动手。自己实现数据库最直接的好处是完全掌控。你可以根据业务特点定制存储结构比如我们电商系统就针对JSON做了特殊优化。其次学习价值巨大。通过实现事务、索引等核心机制你会真正理解为什么MySQL的隔离级别要这么设计、B树索引究竟快在哪里这些问题。MYDB就是在这种背景下诞生的轻量级数据库。它采用Java实现核心代码不到1万行但完整包含了事务管理、数据存储、版本控制等关键模块。下面这张表对比了MYDB与主流数据库的差异特性MYDBMySQLSQLite存储引擎自研页式存储InnoDB/MyISAMB-tree事务隔离级别读已提交四种级别可选串行化索引类型B树多种索引B-tree适合场景嵌入式/学习企业级应用移动端2. MYDB的整体架构设计2.1 模块化分层架构MYDB采用经典的分层设计从上到下分为五个核心模块TBMTable Manager负责解析SQL语句管理表和字段元数据。就像公司的前台接收外部请求并分发给对应部门。IMIndex Manager基于B树实现索引功能。我们优化了节点大小使其完全匹配8KB的页面尺寸减少磁盘IO。VMVersion Manager这是最复杂的模块实现了MVCC多版本控制。我在这里踩过坑最初没处理好版本链导致事务回滚时数据错乱。DMData Manager直接管理数据文件和日志。采用预写日志(WAL)机制任何修改前先写日志确保崩溃恢复能力。TMTransaction Manager最底层模块通过XID文件跟踪事务状态。相当于公司的考勤系统记录每个员工的在岗状态。2.2 数据流向示例当执行UPDATE user SET name张三 WHERE id1时数据流动是这样的TBM解析SQL定位user表的id1记录IM通过B树快速找到记录位置VM检查该记录是否被其他事务锁定DM从缓存或磁盘加载对应数据页TM标记当前事务为进行中状态修改完成后DM先写日志再更新数据页这种设计最大的优势是职责清晰。每个模块只需要关心自己的领域通过标准接口交互。我在初期版本曾让DM直接处理事务结果代码很快变得难以维护。3. 存储引擎的实现细节3.1 页面管理数据库的内存模型MYDB采用固定8KB的页面大小可配置这与操作系统的内存分页机制非常契合。每个页面包含页头元数据16字节记录页号、校验和、修改标志等空闲空间偏移量2字节指向页内可用空间的起始位置实际数据剩余空间采用slotted array结构管理记录这种设计带来三个好处批量读写高效8KB正好是SSD的最佳写入单元缓存友好整页加载到内存减少碎片崩溃恢复简单以页为单位校验和修复实际测试中这种页式存储比直接操作文件快3-5倍。特别是在批量插入场景我们通过预分配连续页面进一步提升了性能。3.2 日志与恢复永不丢失的承诺数据库最怕什么突然断电导致数据损坏。MYDB通过日志机制解决这个问题其核心是三条铁律日志先行任何数据修改前必须先写日志强制刷盘日志写入后立即调用fsync幂等操作日志内容要支持重复执行日志格式设计也很有讲究// 日志条目结构 class LogEntry { int size; // 数据部分长度 int checksum; // 校验和 byte[] data; // 实际数据 }恢复流程分三步走分析日志找出未完成的事务对已提交事务执行redo重做对未完成事务执行undo撤销这里有个优化点定期做checkpoint记录当前活跃事务可以大幅缩短恢复时间。4. 事务管理的艺术4.1 XID文件的巧妙设计事务状态存储在一个叫XID的文件中其结构非常简单前8字节记录事务总数long类型后续每个事务1字节存储状态0x01活跃0x02已提交0x03已中止这种设计实现了O(1)时间复杂度的状态查询。比如检查xid5的事务状态// 计算偏移量 long offset 8 (xid - 1); // 读取状态字节 byte status fileChannel.read(offset);4.2 MVCC与锁的平衡术MYDB实现了读已提交隔离级别核心机制是多版本控制每条记录保留历史版本形成版本链快照读读操作访问对应时间点的版本完全无锁当前读写操作需要获取记录锁防止并发修改版本记录的关键字段class Version { long xmin; // 创建该版本的事务ID long xmax; // 删除该版本的事务ID byte[] data;// 实际数据 }这种设计完美解决了脏读问题但需要注意版本回收。我们采用简单的策略事务提交后其创建的版本至少保留300秒可配置。5. 性能优化实战经验5.1 缓存策略的选择最初采用LRU缓存但遇到严重问题大查询可能挤掉热点数据。后来改用引用计数缓存关键实现如下class CacheEntry { Object data; // 缓存数据 int refCount; // 引用计数 boolean dirty; // 是否为脏页 void release() { if(--refCount 0) { if(dirty) flushToDisk(); cache.remove(this); } } }这种方案虽然内存占用稍高但行为完全可预测。实际测试显示在混合读写场景下其性能比LRU稳定20%以上。5.2 B树索引的优化MYDB的B树有三个特别设计页对齐每个节点正好8KB与存储页一一对应预分裂插入时预测分裂减少磁盘操作懒删除删除标记而非立即重组提升并发性叶子节点的紧凑布局| 键1 | 指针1 | 键2 | 指针2 | ... | 下一个叶子页指针 |在百万级数据测试中这种索引比哈希表慢15%的写入但查询速度快3倍且支持范围查询。实现数据库最深的体会是每个设计决策都要权衡。比如选用引用计数而非LRU牺牲了内存效率换取了确定性采用MVCC虽然增加了存储开销但大幅提升了并发性能。这些经验让我在使用商业数据库时能更准确地评估不同配置的优劣。