一位做过数据库克隆工具的开发者,公开了自建项目 Homescale 的第一阶段架构。它用 Kubernetes 编排、Ceph RBD 做块存储、写时复制(COW)快照给 PostgreSQL 创建可写分支,不用每次整库复制一份数据。代码放在 homescale-dev/homescale,目前只适配 Postgres 一种引擎。
Homescale 证明的是,把数据库分支能力下沉到通用存储层这件事技术上可行。但它现在只是本地单节点的原型工具,离 PlanetScale 那种开箱即用的商业化分支服务还很远——把它叫成"PlanetScale 平替",为时过早。
分支怎么切出来:image、container、branch三级模型
Homescale 借用了 Docker 的镜像/容器概念。image 是不可变的起点,container 是从镜像克隆出的可写实例,branch 是从容器当前状态再切出的另一个可写容器。命令行大致是 image create、container create、branch create 三步。
背后靠的是 Ceph RBD 的快照分层。切分支时,Ceph 先给源容器打一个快照,再从快照克隆出新的可写卷。两个 Postgres 进程互不知道对方存在,各自只看自己的块设备。
作者举了个例子:100GB 的数据库做分支,创建时不用马上多占 100GB 空间,成本主要是元数据——这只是原理说明,不是实测数据。分支之后随着两边写入内容分叉,占用空间会持续增长。Ceph 默认按 4MB 一个对象切分数据,分支第一次改动共享内容时,哪怕只写几个字节,也可能要把整个 4MB 对象搬过去,小写入被放大成大开销。
走哪条路线:通用块存储,还是数据库专用存储
存算分离不新鲜。Amazon RDS 把数据文件放在 EBS 上,Google Cloud SQL 用 Persistent Disk,数据库进程看到的还是普通块设备——这是 Homescale 走的路。Aurora、AlloyDB、Azure SQL Hyperscale 更进一步,存储层专门为数据库设计,能理解事务和日志,计算节点扩缩不用整份复制数据。
还有一条更贴近 Homescale 目标的对照:Neon。Neon 为 Postgres 做了日志级的写时复制分支,存储层原生理解 WAL,不是靠通用块设备快照拼出来的。Homescale 现在做的事,跟 Neon 的产品目标接近,但实现路径不同——它没有重写存储引擎,只是把 Ceph RBD 的快照能力接进 Kubernetes,靠 PVC 和 VolumeSnapshot 这套标准接口驱动分支操作。
| 路线 | 代表产品 | 存储层设计 | 分支实现 |
|---|---|---|---|
| 通用块存储+快照 | RDS、Homescale | 通用块设备 | 整卷快照克隆 |
| 数据库专用分布式存储 | Aurora、AlloyDB、Azure SQL Hyperscale | 为数据库设计 | 存储层原生共享 |
| 日志级写时复制 | Neon | Postgres 专用 | WAL 层面复制 |
省下全量复制,不等于省下运维和一致性责任。
Ceph 打快照时并不知道 Postgres 是否处于可安全恢复的状态,块设备一致不代表数据库文件一致。生产用途还得靠数据库自身的检查点或预写日志机制配合——Ceph 能抓到卷状态,不代表任意快照都能安全恢复。
谁该关注,谁该再等等
对负责 Postgres 开发测试环境的平台工程团队,Homescale 值得跟。它解决的正是"给每个 PR 开一个数据库分支"这类场景,不用等整库复制跑完。但生产环境的副本管理,现在别碰:本地单节点、单 OSD 只有一份数据,没有高可用,一次宕机就是丢数据。
对评估自建分支能力的基础设施和存储工程师,现在的判断依据还不够。作者没给出写放大的实测数字,没讲清分支越切越多之后怎么回收空间,也没验证过故障恢复。真要立项自建,先等作者把 Ceph 多节点、三副本、故障域这部分补上,或者先拿 Neon 这类现成产品做对照评估,再决定是否值得自己搭一套。
作者提到,未来可能接入他在 Hetzner 跑的私有 Talos 集群,用三副本、按主机划分故障域的方式部署,但这部分工作还没做。数据库层面的一致性快照问题,作者留到了后续文章,目前还看不清具体方案。