Dolt 2.0 是开源版本化 SQL 数据库的一次重要升级。它把数据库的 Git 式版本管理能力，进一步延伸到存储生命周期管理：自动垃圾回收和压缩可以减少长期运行后的存储膨胀，同时新版也改进了对大型数据类型和向量数据的支持。
这意味着 Dolt 不再只是“能提交、能分支、能合并的 SQL 数据库”。对于需要保留历史版本、审计数据变化，或者管理机器学习数据集的团队来说，存储成本和数据规模也开始成为可以纳入设计的实际问题。
为什么存储优化对版本化数据库重要
普通数据库通常只需要关注当前状态；版本化数据库还会保存提交、分支和历史数据。数据不断更新时，旧版本仍然可能被查询或恢复，因此存储空间不会像传统数据库那样只随着当前表大小增长。
这种历史能力很有价值，但也带来两个工程问题：
- 被旧提交引用的数据不能随意删除，否则历史版本会损坏。
- 数据长期写入后，重复内容和过期对象可能持续占用磁盘空间。
Dolt 2.0 将垃圾回收和压缩纳入自动存储优化能力。垃圾回收负责识别不再被版本历史引用的对象，压缩则帮助降低数据在磁盘上的占用。对于频繁导入、反复修改或拥有大量分支的仓库，这类能力直接影响备份大小、磁盘预算和维护窗口。
需要注意的是，垃圾回收不是“删除所有旧版本”。仍被分支、标签或提交历史引用的数据必须保留。生产环境应结合保留策略、备份策略和恢复要求评估回收时机。
大型数据与向量数据带来的变化
Dolt 2.0 也改进了对大型数据类型和向量数据的支持。大型文本、二进制内容、特征向量或模型相关数据，往往比传统业务表中的整数和短字符串更容易放大存储、导入和查询成本。
把这类数据放进版本控制系统的好处是明显的：数据集、特征定义和业务代码可以围绕同一套提交历史协作，团队可以追踪某次实验使用了哪一版数据。不过，版本化并不等于所有大对象都应该直接塞进一张表中。实际设计时仍要考虑：
- 向量数据是否需要频繁更新；
- 是否需要对向量进行相似度检索；
- 单次提交会产生多少新增数据；
- 是否需要长期保留每一个实验版本；
- 备份和跨环境同步的带宽是否足够。
可以把 Dolt 用作结构化元数据、数据集快照和实验结果的版本中心；对于特别大的原始文件，则可以结合对象存储，并在 Dolt 中保存内容哈希、路径和版本信息。这样既保留可追溯性，也避免让单个数据库仓库承受不必要的二进制增长。
一个可运行的最小实践
下面的示例假设本机已经安装 Dolt，并且 dolt 已经在 PATH 中。它创建一个版本化数据库，写入一张实验数据表，提交两次变更，然后运行存储清理命令。命令可以直接复制到临时目录中运行：
set -e
rm -rf dolt20-demo
mkdir dolt20-demo
cd dolt20-demo
dolt init
dolt sql -q '
CREATE TABLE experiments (
id BIGINT PRIMARY KEY,
model_name VARCHAR(128) NOT NULL,
dataset_version VARCHAR(128) NOT NULL,
vector_json LONGTEXT,
metrics_json LONGTEXT
);
'
dolt sql -q '
INSERT INTO experiments
(id, model_name, dataset_version, vector_json, metrics_json)
VALUES
(1, "embedding-model-a", "dataset-2024-01", "[0.12,0.34,0.56]", "{\"accuracy\":0.91}");
'
dolt add experiments
dolt commit -m "add first experiment"
dolt sql -q '
UPDATE experiments
SET dataset_version = "dataset-2024-02",
metrics_json = "{\"accuracy\":0.93}"
WHERE id = 1;
'
dolt add experiments
dolt commit -m "update experiment result"
echo "Current history:"
dolt log --oneline
echo "Running storage cleanup:"
dolt gc
示例中的 vector_json 和 metrics_json 使用文本保存，是为了让脚本在不同 Dolt 构建和环境中更容易运行。实际项目可以根据所用版本支持的向量类型，将 vector_json 替换为对应的向量列，并为查询模式设计合适的索引。Dolt 2.0 对大型数据和向量数据的支持有所改进，但具体类型、索引能力和相似度查询语法仍应以目标版本的文档和 dolt sql 实际行为为准。
在生产环境中，建议把 dolt gc 纳入可观测的维护流程，而不是无条件地放进每次提交之后。可以先在副本或测试仓库中统计回收前后的目录大小，再结合备份完成状态执行清理。对于需要完整历史审计的仓库，还应明确哪些分支和标签必须长期保留。
升级时应检查什么
Dolt 2.0 的价值不只在于新增几个命令，而在于版本历史、存储管理和大数据类型开始形成更完整的组合。升级或新建仓库时，可以按下面的清单验证：
- 确认现有客户端、服务器和自动化脚本与 2.0 兼容。
- 在副本上验证历史查询、分支、合并和回滚流程。
- 记录垃圾回收前后的磁盘占用和执行时间。
- 检查备份是否覆盖版本对象，而不只是当前表数据。
- 为大型文本、二进制数据和向量数据设置提交大小与保留周期。
- 明确对象存储和 Dolt 仓库之间的引用、哈希和恢复关系。
对于小型、短生命周期的数据集，自动清理可能不是主要收益；而对于持续积累历史版本、频繁创建分支，或者需要管理机器学习数据的团队，Dolt 2.0 提供了更适合长期运行的存储基础。采用时应把数据保留、恢复目标和查询需求一起设计，而不是只关注数据库文件是否变小。