Dolt:把 Git 的分支、提交、合并搬进 SQL 数据库
Dolt 是兼容 MySQL 协议的 SQL 数据库,内置 Git 语义:对数据表直接 branch、commit、diff、merge、log。基于 Prolly Tree 内容寻址存储,提交近乎瞬时。应用无需改代码即可接入,还能跑成 MySQL Server。
Dolt = MySQL 兼容的关系数据库 + 刻进内核的 Git 工作流。代码世界的 branch、commit、diff、merge、log,对数据库表原样适用。它实现了 MySQL 协议,是即插即用的 MySQL 替代品——任何连 MySQL 的应用或工具,不改一行代码就能连上 Dolt。
为什么需要它
两种传统方案都有硬伤:
- 传统关系库(MySQL/PostgreSQL):有 Schema 约束和强大查询,但变更立即生效且常不可逆——没有内置 diff、没有提交历史(除非自建审计表)、没有干净的回滚;
- 把数据放进 Git(CSV/JSON/YAML):有版本控制和 PR 流程,但牺牲了全部数据库能力——没有主键、没有类型约束、查询要先解析整个文件;而且 CSV 的 diff 是行级的,难审查、易冲突。
Dolt 两头都要:完整 SQL 能力 + 内置 Git 工作流。
底层原理:Prolly Tree
传统数据库用 B-Tree,为读写优化,没考虑版本化。Dolt 用 Prolly Tree(概率 B-Tree):内容寻址、不可变的数据结构,每个节点由内容哈希标识。
数据变化时,Dolt 不修改旧树——只为变化的数据创建新的父节点链,未变的节点直接复用指针。所以一次 commit 只存增量数据和新指针:无论库有多大,分支、diff、提交都近乎瞬时。这也是两个版本间 diff 能做到单元格级的原因。
上手流程
mkdir dolt-tutorial && cd dolt-tutorial
dolt init # 生成 .dolt 目录(历史、配置、元数据)
dolt sql # 进入交互式 SQL shell
CREATE TABLE employees (
id INT NOT NULL,
name VARCHAR(255),
title VARCHAR(255),
PRIMARY KEY (id)
);
INSERT INTO employees VALUES
(1, 'Alice Johnson', 'Software Engineer'),
(2, 'Bob Williams', 'Product Manager'),
(3, 'Charlie Brown', 'Data Analyst');
UPDATE employees SET title = 'Senior Data Analyst' WHERE id = 3;
退出 shell 后,用 Git 的方式管理变更:
dolt status # 哪些表有改动
dolt diff # 单元格级结构化 diff:哪行哪列变了
dolt add employees
dolt commit -m "Promote Charlie Brown to Senior Data Analyst"
分支与合并:
dolt checkout -b add-feature-flags
dolt sql -q "CREATE TABLE feature_flags (flag_name VARCHAR(100) PRIMARY KEY, is_enabled BOOLEAN);"
dolt sql -q "INSERT INTO feature_flags VALUES ('new-dashboard', false);"
dolt add feature_flags && dolt commit -m "add feature flags"
dolt checkout main
dolt merge add-feature-flags # 冲突会像 Git 一样报出来
审计日志:dolt log 查看提交历史,任何时候都能 dolt checkout <commit> 回到历史快照——误删数据?回滚就是一次 checkout。
两种用法:CLI 工具或 MySQL Server
- CLI 模式:像 Git 管理代码库一样管理数据文件,适合数据工程、离线数据集版本化;
- Server 模式:
dolt sql-server启动一个兼容 MySQL 协议的服务,现有应用的连接串改个端口就接上了。配套的 DoltHub 则扮演 GitHub 的角色:托管数据库仓库、Pull Request 式数据评审。
典型适用场景
- 数据集版本化:ML 训练数据、参考数据集的分支管理与评审;
- 配置与主数据:功能开关、价格表、规则库——变更可评审、可回滚;
- 审计刚需场景:金融、医疗数据的每一次变更天然留痕;
- 数据协作:多人通过分支并行改数据,合并时单元格级冲突检测。
不适合:纯高频 OLTP 写入主库(版本化有额外存储开销);不需要任何历史追溯的缓存型数据。
观测云对照
把 Dolt 跑成 MySQL Server 后,观测云 DataKit 的 MySQL 集成可以直接采集它的连接、查询、慢 SQL 等指标(协议兼容带来的红利);配合监控器对慢查询和连接数设告警,把它当成一个普通 MySQL 来运维观测即可。 1 2
常见问题(FAQ)
Q:Dolt 性能和普通 MySQL 比如何?
读性能接近;写路径因为要维护 Prolly Tree 版本结构,吞吐低于原生 MySQL。它解决的是"版本化"问题,不是"更快的 MySQL"。
Q:数据量大了之后历史会不会把磁盘吃光?
Prolly Tree 只存增量,但历史毕竟累积。Dolt 提供垃圾回收机制清理不再引用的旧版本,可按需执行。
Q:Merge 冲突怎么处理?
和 Git 类似:合并时冲突会被标记,由人介入选择保留哪边(单元格粒度),处理完提交合并结果。
Q:能替代 Flyway/Liquibase 这类迁移工具吗?
定位不同。迁移工具管 Schema 演进脚本,Dolt 管数据与 Schema 的版本历史。用 Dolt 时 Schema 变更本身就是 commit 的一部分,两者可互补。