CloudJump III Optimizing Cloud Databases for Tiered Storage(SIGMOD 2026)
在云原生数据库的演进中, 计存分离让计算层和存储层可以独立扩展, 共享存储让多个计算节点访问同一份数据成为可能.
MySQL数据库内核研发相关
在云原生数据库的演进中, 计存分离让计算层和存储层可以独立扩展, 共享存储让多个计算节点访问同一份数据成为可能.
前面介绍过 PostgreSQL Buffer Access 5 Rules 里面的 Pin 机制, 其实 HeapTable + Pin 机制还带来了其他和 InnoDB 的区别.
src/backend/storage/buffer/README 是 PG 社区维护 buffer manager 的官方设计文档. 它在开头列了 5 条 buffer access rules, 提 patch / review 时直接引用. 这 5 条规则合起来定义了 PG 的 Pin 协议, 也是 PG 和 InnoDB buffer manager 设计上真正分叉的地方.
在 MySQL/PostgreSQL Buffer Pool 里面有一个 Pin 操作 — PostgreSQL 叫 Pin, MySQL InnoDB 叫 buf_block_fix / io_fix. 这些操作本质上都是把一个 page “pin” buffer pool 的某个位置上.
DuckDB / Velox / Umbra 里面常见的字符串表示方式. 和传统的 SimpleStr (ptr, len) 相比, 都是 16 字节, 但是 layout 不同.
2018 年, PostgreSQL 社区发现了一个存在了 20 年的严重问题: 当 fsync() 失败时, PostgreSQL 的处理方式可能导致静默数据丢失. 这个被称为 “fsyncgate” 的事件, 不仅揭示了 PostgreSQL 自身的架构缺陷, 更暴露了 Linux 内核, 文件系统与数据库之间在 I/O 错误处理上的深层矛盾.
最近一直在探索怎么用 Claude Code 来帮忙写数据库内核的代码. 一开始是直接让 Claude code 在 PostgreSQL 上实现一套 Double Write Buffer, 参考 InnoDB 的实现. 代码 Claude 确实写得挺快, 但过程中发现一个问题: 它不会做设计.
2026 年了, AI 能改数据库内核代码么? 我用 Claude Code 把 PostgreSQL 的 Full Page Write 换成了 MySQL 的 Doublewrite Buffer, 跑出来性能差了 3 倍.
我们看到目前有 3 个主流 PostgreSQL 集成 DuckDB 的方案在运行 pg_duckdb,pg_mooncake, pg_lake.
MySQL的插件式存储引擎架构