SQLite als Repository: Komprimierung löscht die Historiensteuer

Die Textversionierung in relationalen Datenbanken hat traditionell zwei schmerzhafte Enden. Entweder Sie speichern jedes Diff separat und die Versionsrekonstruktion erfordert Anwendungslogik, oder Sie speichern bei jedem Speichern eine vollständige Kopie des Dokuments, und die Datenbank bläht sich schnell auf. Simon Willison untersuchte einen dritten Weg: die Speicherung der gesamten Historie eines Dokuments als eine einzige komprimierte binäre Spalte in SQLite.

Die brutale Effizienz der Komprimierung redundanter Daten

Das Prinzip ist einfach. Die Historie ist ein einzelnes JSON-Array, an das bei jedem Speichern eine neue vollständige Kopie des Textes angehängt wird. Damit es nicht die Festplatte auffrisst, wird das Array vor dem Speichern durch den Zlib- oder Zstandard-Algorithmus (ZSTD) geführt. Da die vorherige und die neue Version die überwiegende Mehrheit der Zeichen gemeinsam haben, ist die Komprimierung äußerst effektiv. In einem Experiment mit 1.000 Dokumentüberarbeitungen schrumpften 20,4 MB Rohtext auf 80,3 KB. Die Datenbank speichert Zeitstempel in einer unkomprimierten Spalte nebenan, um schnelle Abfragen zu ermöglichen.

Die Grenze eines großen Blobs erreichen

Die Architektur „Alles in einem Blob“ hat jedoch eine Obergrenze. Bei jedem neuen Speichern muss die Datenbank die gesamte Historie dekomprimieren, den neuen Datensatz anhängen und alles wieder komprimieren. Dies ist bei langen Historien rechenintensiv. Willisons Experiment führte daher einen zweiten Prototyp ein, der die Historie in Chunks aufteilt. Sobald ein Blob 128 Überarbeitungen oder 3 MB unkomprimierte Daten erreicht, wird er versiegelt, und neuer Text fließt in die nächste Zeile.

Konflikte in einer verteilten Umgebung

Die Einfachheit der Lösung verbirgt einen Haken für den Produktionseinsatz. Konfliktlösung. Der Prototyp verlässt sich derzeit auf eine grobe BEGIN IMMEDIATE Sperre, um Schreibvorgänge zu serialisieren. Für eine lokale SQLite-Instanz ist dies eine akzeptable Lösung, aber in verteilten Systemen wäre dies ein erheblicher Engpass.

Der Weg zu Offline-First-Anwendungen ohne git

Der Erfolg dieses Musters ebnet den Weg für Offline-First-Anwendungen, die eine lokale Historie ohne Git-Abhängigkeit benötigen. Es ermöglicht, die komplette Historie direkt bei den Daten zu halten, ohne das Risiko einer schnellen Erschöpfung des Speicherplatzes auf Endgeräten.

Liliths Urteil

Einem Komprimierungsalgorithmus einen Haufen fast identischen Textes zu übergeben, ist ein alter Trick, aber ihn direkt in einer Datenbankspalte zu verpacken, ist eine wunderbar faule Architektur, die komplexe Versionierungsbibliotheken begraben könnte.