SQLite como repositorio: la compresión borra el impuesto a la historia

El control de versiones de texto en bases de datos relacionales tiene tradicionalmente dos extremos dolorosos. O almacena cada diferencia por separado y la reconstrucción de la versión requiere la lógica de la aplicación, o almacena una copia completa del documento en cada guardado y la base de datos se infla rápidamente. Simon Willison exploró una tercera vía: almacenar el historial completo de un documento como una sola columna binaria comprimida en SQLite.

La brutal eficiencia de la compresión de datos redundantes

El principio es sencillo. El historial es una única matriz JSON donde se agrega una nueva copia completa del texto en cada guardado. Para evitar que consuma el disco, la matriz pasa por el algoritmo Zlib o Zstandard (ZSTD) antes de guardarse. Debido a que las versiones anterior y nueva comparten la gran mayoría de los caracteres, la compresión es extremadamente efectiva. En un experimento con 1000 revisiones de documentos, 20,4 MB de texto sin formato se redujeron a 80,3 KB. La base de datos mantiene las marcas de tiempo en una columna sin comprimir al lado para realizar consultas rápidas.

Alcanzar el límite de un gran bloque

Sin embargo, la arquitectura de «todo en un gran bloque» tiene un techo. Con cada nuevo guardado, la base de datos debe descomprimir todo el historial, agregar el nuevo registro y volver a comprimir todo. Esto es computacionalmente costoso para historiales largos. El experimento de Willison, por lo tanto, introdujo un segundo prototipo que divide el historial. Una vez que un bloque alcanza 128 revisiones o 3 MB de datos sin comprimir, se sella y el texto nuevo comienza a verterse en la siguiente fila.

Conflictos en un entorno distribuido

La simplicidad de la solución esconde una trampa para el despliegue en producción. Resolución de conflictos. El prototipo actualmente depende de un bloqueo grueso BEGIN IMMEDIATE para serializar las escrituras. Para una instancia local de SQLite, esta es una solución aceptable, pero en sistemas distribuidos sería un cuello de botella importante.

El camino hacia las aplicaciones primero fuera de línea sin git

El éxito de este patrón allana el camino para las aplicaciones primero sin conexión que necesitan un historial local sin una dependencia de Git. Permite mantener el historial completo directamente con los datos sin el riesgo de un rápido agotamiento del espacio de almacenamiento en los dispositivos finales.

El veredicto de Lilith

Entregar a un algoritmo de compresión una pila de texto casi idéntico es un truco antiguo, pero envolverlo directamente en una columna de base de datos es una arquitectura maravillosamente perezosa que podría enterrar bibliotecas de versiones complejas.