SQLite Zstd 进阶压缩：三表方案把 500 万条日志从 4.27GB 压到 1.01GB

📝

两双筷子的 SQLite 日志压缩第二弹：第一代逐行 Zstd 压缩（150 字节以上才压）空间节省不够用，升级为三表方案——日志索引表 + 日志详情表 + 日志压缩表，任务结束后把多条相似详情合并成区块统一压缩。实测 500 万条日志：明文行存 4.27GB → 逐行压缩 2.59GB → JSON 区块压缩 1.01GB。附 JSON vs MessagePack 对比：序列化更小的 MessagePack 反而压缩后更大。

原文链接：https://mp.weixin.qq.com/s/uWzzogtzyA533OHqzLPfqA（两双筷子）
系列前篇：《SQLite 压缩存储日志》——第一代方案：日志从 MySQL 独立，按月写入 SQLite 文件，单条超过 150 字节时用 Zstd 压缩

起因：逐条压缩的瓶颈

日志量继续上来以后，逐条压缩的空间节省开始不够用。原因很直接：很多日志的字段名、状态和固定输出会反复出现，变化的可能只有 ID、时间和少量结果字段。第一代方案每条日志单独交给 Zstd，每次压缩只看到当前一条——前面出现过的重复内容，后面还得再压一次。

思路来自 ClickHouse：数据先写进去，后台慢慢做合并和压缩。日志没必要照搬 ClickHouse 实现，但这个方向很适合历史日志。

问题：直接拼起来压缩会踩坑

把多条日志直接拼起来压缩，看起来简单，实际有麻烦：一条日志写入过程中内容可能继续补充。假设一个压缩包里已有 1000 条详情，其中一条又多输出了几行——更新它需要先解压整个压缩包，改完再压回去。一次很小的写入变成重写 1000 条日志。

所以日志要分开存：任务执行时详情按原方式写入，任务结束后确认不再变更，再批量压缩归档。

改进：三表拆分

把一条完整日志拆成三部分：

表	存什么	用途
日志索引表	时间、任务 ID、状态、列表摘要、压缩包定位	列表、筛选、统计（不碰大字段，无需解压）
日志详情表	还会继续追加的完整日志	任务执行期间写入
日志压缩表	多条历史详情合并后的 Zstd 数据	长期保存（每行 = 一个压缩包，几百~几千条）

写入流程：任务开始写日志 → 同时写索引表和详情表；列表页查索引表，不碰详情表。

归档流程：任务结束后后台取一批详情，每条前面写长度（解压后能区分边界），整段压缩：

1
2
3

[第 1 条详情长度][第 1 条详情内容]
[第 2 条详情长度][第 2 条详情内容]
...

压缩完成后同一个事务里做三件事：① 写入压缩表拿 block_id；② 更新索引表记录每条日志的 block_id 和序号；③ 删除详情表已归档内容。归档任务下次只查 block_id 为空的记录。

为什么必须一个事务：中间任意一步失败整批回滚，详情表还在下次可继续归档。分开提交可能出现「索引指向不存在的压缩包」或「详情删了却找不到归档数据」。

查询流程：列表照常查索引表；打开某条完整日志时先查 block_id——为空直接读详情表，有值则解压对应压缩包按序号取出。一个列表页多条日志落在同一压缩包时，请求内缓存解压结果避免重复解压。

按月保存 SQLite 文件的做法保留，过期直接删月份文件，索引/详情/压缩一起清掉。

效果：500 万条日志实测

存储方式	占用空间
SQLite 明文行存	约 4.27 GB
逐行 Zstd 压缩	约 2.59 GB
三表 JSON 区块压缩	约 1.01 GB
三表 MessagePack 区块压缩	约 1.18 GB

从压缩包随机打开一条详情约几毫秒（逐行压缩数十微秒）。区块归档省下大量空间，历史详情打开略慢，列表查询不受影响。

JSON vs MessagePack：反直觉的结论

每 1 万条详情合并后交给 Zstd，区别只是载体换成 MessagePack：

指标	JSON	MessagePack
压缩前详情	约 4027.69 MB	约 3072.02 MB
Zstd 后详情	约 83.37 MB	约 259.46 MB
数据库总大小	约 1.01 GB	约 1.18 GB
写入速度	约 31365 条/秒	约 23699 条/秒
随机详情读取	约 3.5ms	约 4.6ms

MessagePack 序列化后原始详情确实更小（3072 vs 4027 MB），但 JSON 里重复的字段名和固定文本多，区块压缩能利用这些重复；MessagePack 把字段名换成紧凑二进制，原始数据少了，Zstd 能利用的重复也少了——压缩后反而更大。

结论：JSON 区块 + Zstd。但只针对当前样本，换日志结构要重新测；比较要看压缩后体积、写入速度、详情读取耗时，不能只看序列化原始大小。

适用范围

逐行压缩更合适：日志长时间追加、不同日志重复内容不多、用户经常打开完整详情
可以混用：最近几天逐行压缩，时间更久、主要排查问题的日志做区块归档

技术栈：Go + SQLite + github.com/klauspost/compress（Zstd）。

观察

这篇文章的价值在于区块压缩的三个设计决策：① 任务结束才归档（避免热更新压缩包）；② 三表拆分（索引与详情解耦，列表查询零解压）；③ 归档三步走必须单事务（一致性兜底）。第②点尤其漂亮——把「要频繁查的元数据」和「要压缩的大字段」物理分离，是日志存储的通用套路。JSON vs MessagePack 的对比也提醒：压缩前保留可预测的冗余，往往比极致紧凑的序列化更利于压缩器。