Simon Willison、SQLite の圧縮テキスト履歴プロトタイプを検証
本文の状態
日本語全文を表示中
詳細モードで約3分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Simon Willison Blog
Simon Willison は SQLite の改訂履歴保存において、全バージョンを JSON 配列として圧縮する実験的アプローチを実装し、その有効性を示した。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るAI深層分析を開く2026年8月13日 07:14
AI深層分析
キーポイント
圧縮による履歴保存の提案
Simon Willison は、SQLite の単一カラムに過去の全バージョンを JSON 配列として格納し、zlib や zstd で圧縮する仕組みを考案した。
音声機能と AI を活用した検討
同氏は ChatGPT の GPT-Live 音声モードおよび GPT-5.6 Sol Pro と対話し、アイデアの具体化とコード生成を支援させた。
実装プロトタイプの成果
Python を用いた実験的プロトタイプにより、1,000 回の改訂シミュレーションで元のデータ量の大幅な削減に成功したことが確認された。
圧縮効率の向上
1,000回のシミュレーションによる20.4 MBの生テキストが、Zstandardで圧縮されたJSON配列として80.3 KBに圧縮される。
編集時のオーバーヘッド回避
Solは、各編集時に配列全体を解凍・再圧縮する負荷を避けるため、履歴を複数の行に分割することを提案した。
重要な引用
how about taking the full text of every prior version in a big JSON array of strings and then applying zlib or zstd compression to the whole thing?
The approach works really well! 1,000 simulated revisions to a document resulted in 20.4 MB of raw revis
1,000 simulated revisions to a document resulted in 20.4 MB of raw revision text that compressed to 80.3 KB as Zstandard-compressed JSON array.
To avoid the overhead of decompressing and recompressing the entire array on every edit Sol suggested breaking the history up into multiple rows, with each one containing a maximum of either 128 revisions or 3MB of uncompressed JSON.
編集コメントを表示
編集コメント
Simon Willison は、既存のデータベース技術と最新の生成 AI を組み合わせることで、長年の課題であった履歴保存の効率化に新たな視点をもたらした。このアプローチは、特に大規模なドキュメント管理システムにおけるストレージ最適化の選択肢として注目される。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
私はリレーショナルデータベースにおける改訂履歴の保存方法について、常に新しい選択肢を探しています。ある日犬の散歩をしている最中に、ふと面白いアイデアが浮かびました。それは、過去のすべてのバージョンの全文を文字列の大きな JSON 配列にまとめ、その全体に対して zlib や zstd などの圧縮アルゴリズムを適用するというものです。繰り返し出現する文字列が多いため、これは非常に高い圧縮率を発揮するはずです。
ChatGPT iPhone アプリで新たに導入された GPT‑Live ボイスモード が驚くほど優秀になったので、このプロトタイプについて AI と議論してみました。まだボイス通話の URL を共有することはできませんが、以下は会話の内容をそのまま書き起こしたものです。
SQLite データベースの 1 つの列に、頻繁に編集されるテキストのすべての過去バージョンを保存する効率的なスキームについて、面白いアイデアがあります。以前にも同様のシステムを構築したことがありますが、常に効率的な方法を見つけるのは難しかったです。
最も簡単な方法は、文字列の過去の値（前回の値、さらにその前の値など）それぞれに対して行を作成することです。しかし、20 キロバイトのような長いドキュメントの場合、編集するたびにデータベースに 20 キロバイトずつデータが追加されてしまいます。
そこで私が考えているのは、圧縮を活用する方法です。文書のすべてのバージョンを最初からまとめて、適切な圧縮アルゴリズムを適用すれば、重複するテキストの大部分を削減できるはずです。
具体的には、非常にシンプルな仕組みを考えました。このテーブルには「履歴（history）」という列があり、これは BLOB 型でバイナリデータを格納します。そこに、過去のすべてのドキュメントを含む JSON テキスト配列を Zlib や ZSTD で圧縮して保存するのです。
おそらく 2 つの列が必要になります。1 つ目は、テキストの魔法のような JSON 配列を格納する列です。もう 1 つはタイムスタンプの JSON 配列を格納する列で、こちらは圧縮する必要はありません。タイムスタンプは整数（Unix タイムスタンプ）の配列として扱えるからです。
これが全体のプロセスです。
その後、音声入力を停止し、GPT-5.6 Sol Pro に対して以下のテキストプロンプトを入力しました。
Use Python and Build experimental prototypes around this idea
この指示は約38分間処理され、こちらの回答 と、こちらフォルダ にあるファイル群が生成されました。
このアプローチは非常に効果的です。文書に対して 1,000 回のシミュレーションされた改訂を加えた結果、20.4 MB の生データが Zstandard で圧縮された JSON 配列として 80.3 KB にまで圧縮できました。
Sol は、すべての編集のたびに配列全体を解凍・再圧縮するオーバーヘッドを避けるため、履歴を複数の行に分割することを提案しました。各行には最大で 128 件の改訂、または未圧縮の JSON で 3MB のデータを含めるように設定します。
Tags: compression, sqlite, speech-to-text
原文を表示
Research: SQLite compressed text-history prototypes
I'm perennially interested in options for storing revision histories in relational databases. While out on a dog walk I had a new idea: how about taking the full text of every prior version in a big JSON array of strings and then applying zlib or zstd compression to the whole thing? Surely that would compress really well due to all of the repeated strings.
The new GPT‑Live voice mode in the ChatGPT iPhone app has got really good, so I discussed the prototype with that. You still can't share URLs to voice conversations, but here's what I said copied from the transcript as a proper stream of consciousness:
I have an interesting idea for a scheme for saving all previous versions of a piece of text that's constantly edited in a SQLite database um column in as efficient a way as possible. Okay, so I built these kinds of systems in the past, and it's always difficult to come up with a efficient way to do this. Like the easiest way is you have a row for every previous copy of the previous previous value of the string. But if it's a long document Like20 kilobytes of data, that means that every single edit adds another 20 kilobytes of data to the database, right. So, what I've now thinking, is um compression would work really well, right? If you Bundle all of those different um Every every version of this document all the way back to the start if you were to apply a good compression algorithm to them that should basically wipe out huge amounts of the redund- the um redundant text, right Um, so what I'd thinking is how about really, really simple mechanism There is a history column on the single on this uh uh table and it's a blob, it's a BLOB so it stores binary data and then you just stick in there a Zlib or maybe even ZSTD um compressed JSON text array of all of the previous documents, and so you probably have two columns, right? You'd have a column that's this magic JSON array of text You have a second column which is a JSON array of timestamps and that doesn't need to be compressed at all, right? A timestamp can just be a uh- it's an array of integers, right? Unix integers But that's the whole scheme.
Then I stopped voice mode and typed the following text prompt to GPT-5.6 Sol Pro:
Use Python and Build experimental prototypes around this idea
It churned away for 38 minutes and delivered this answer plus the files you see in this folder.
The approach works really well! 1,000 simulated revisions to a document resulted in 20.4 MB of raw revision text that compressed to 80.3 KB as Zstandard-compressed JSON array.
To avoid the overhead of decompressing and recompressing the entire array on every edit Sol suggested breaking the history up into multiple rows, with each one containing a maximum of either 128 revisions or 3MB of uncompressed JSON.
Tags: compression, sqlite, speech-to-text
関連記事
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み