SQLite 压缩文本历史原型
SQLite compressed text-history prototypes
一项针对SQLite中存储文本修订历史的原型实验：将每个先前版本全文放入JSON字符串数组，整体应用zlib或zstd压缩。作者与ChatGPT语音模式讨论该方案，随后向GPT-5.6 Sol Pro输入提示构建Python原型，运行38分钟。对文档进行1,000次模拟修订，原始文本20.4 MB，经Zstandard压缩后仅80.3 KB。Sol建议将历史拆分为多行，每行最多128个修订或3 MB未压缩JSON，以避免每次编辑时解压重压缩的开销。
研究：SQLite 压缩文本历史原型
我一直对在关系数据库中存储修订历史的各种方案感兴趣。在一次遛狗时，我有了一个新想法：把每个先前版本的全文放进一个大的 JSON 字符串数组里，然后对整个数组应用 zlib 或 zstd 压缩，会怎么样？由于存在大量重复字符串，压缩效果应该会非常好。ChatGPT iPhone 应用中的新版 GPT-Live 语音模式已经变得相当出色，于是我和它讨论了这一原型。你仍然无法分享语音对话的 URL，但以下是我从转录中复制的内容，作为一段完整的意识流：
我有一个有趣的想法，关于一种方案，用于在 SQLite 数据库的列中尽可能高效地保存一段不断编辑的文本的所有先前版本。好的，我过去构建过这类系统，要提出一种高效的方法总是很困难。最简单的方式是，为字符串的每个先前副本（即前一个值）都建一行。但如果是一篇长文档，比如 20 千字节的数据，那意味着每次编辑都会向数据库增加另外 20 千字节的数据，对吧。所以，我现在想的是，压缩应该会非常有效，对吧？如果你把所有不同版本——从最开始到现在的每个版本——捆绑在一起，然后对它们应用一个好的压缩算法，那基本上应该能消除大量的冗余文本，对吧。所以，我在想的是，一个非常非常简单的机制怎么样：表上有一个历史列，它是一个 BLOB，存储二进制数据，然后你只需把 Zlib 或甚至 ZSTD 压缩的 JSON 文本数组放进去，包含所有先前的文档。所以你大概需要两列，对吧？一列是这个神奇的 JSON 文本数组，另一列是 JSON 时间戳数组，那根本不需要压缩，对吧？时间戳可以只是一个整数数组，Unix 整数。但整个方案就是这样。
然后我退出语音模式，向 GPT-5.6 Sol Pro 输入了以下文本提示：
使用 Python 并围绕这个想法构建实验原型
它运行了 38 分钟，给出了这个答案以及你在这个文件夹中看到的文件。这种方法效果非常好！对一篇文档进行 1,000 次模拟修订，产生了 20.4 MB 的原始修订文本，压缩为 Zstandard 压缩的 JSON 数组后仅 80.3 KB。为了避免每次编辑时解压并重新压缩整个数组的开销，Sol 建议将历史拆分为多行，每行最多包含 128 个修订或 3 MB 未压缩的 JSON。
标签：压缩、SQLite、语音转文本