Идея для хранения истории версий в базах данных

Девятого августа 2026 года автор вновь вернулся к давнему вопросу поиска оптимальных вариантов для сохранения историй правок в реляционных базах данных. Во время прогулки с собакой у него родилась свежая концепция: что если собрать полный текст каждой предыдущей итерации в единый массив строк формата JSON, а затем применить к полученному объекту алгоритм сжатия zlib или zstd? Логично предположить, что подобный подход должен продемонстрировать отличные показатели компрессии за счет огромного количества повторяющихся текстовых фрагментов.

Обсуждение концепции с голосовым ИИ

Современный голосовой режим GPT-Live в приложении ChatGPT для iPhone работает действительно впечатляюще, поэтому разработчик обсудил свой прототип именно с ним. Прямыми ссылками на аудиодиалоги делиться пока по-прежнему нельзя, однако расшифровку беседы удалось сохранить в виде непрерывного потока мыслей: «У меня появилась любопытная задумка насчет схемы сохранения всех прошлых версий текстового документа, который постоянно редактируется в столбце базы данных SQLite, причем сделать это максимально эффективным способом. Понимаешь, я создавал подобные системы раньше, и подбирать производительные решения всегда тяжело.

Самый очевидный метод заключается в создании отдельной строки для каждой предыдущей копии значения. Но если речь идет о длинном документе размером около 20 килобайт, то каждая новая правка добавляет к базе данных еще по 20 килобайт, верно? Поэтому сейчас я размышляю о том, что компрессия сработала бы прекрасно. Если объединить все версии этого документа вплоть до самой первой и применить к ним качественный алгоритм сжатия, он должен практически полностью уничтожить огромные массивы избыточного текста.

Моя задумка сводится к максимально простому механизму. В таблице присутствует специальная колонка для истории в формате BLOB, которая хранит бинарные данные. Туда просто помещается сжатый с помощью Zlib или даже ZSTD JSON-массив, содержащий все предыдущие редакции документа. Вероятно, понадобится два столбца: первый — для того самого волшебного JSON-массива с текстом, а второй — для массива таймстампов, который вообще не нуждается в компрессии. Метка времени может представлять собой обычный массив целых чисел в формате Unix».

Практическая реализация и результаты тестирования

На этом голосовая сессия завершилась, после чего автор отправил текстовый запрос языковой модели GPT-5.6 Sol Pro с просьбой использовать Python и построить экспериментальные прототипы вокруг предложенной идеи. Нейросеть обрабатывала задачу в течение 38 минут и выдала готовый ответ вместе с набором файлов. Выяснилось, что такой подход функционирует превосходно. Симуляция одной тысячи правок документа, которая в сыром виде давала 20,4 мегабайта текстовой истории, после упаковки в сжатый через Zstandard массив JSON сократилась всего до 80,3 килобайта.

Чтобы избежать колоссальных накладных расходов на распаковку и повторное сжатие всего массива при каждом внесенном изменении, модель предложила разбить общую историю на несколько строк. Каждая отдельная строка должна содержать максимум 128 ревизий либо до 3 мегабайт не сжатых данных в формате JSON.

Источник: simonwillison.net