Uso de SQLite como almacén de contenido estático para un servidor web
Contexto
- Clace es una plataforma diseñada principalmente para ofrecer aplicaciones web para herramientas internas.
- Clace integra funciones que normalmente manejan por separado el servidor web y el servidor de aplicaciones.
- En las primeras etapas del desarrollo de Clace, era importante decidir cómo almacenar los datos y los metadatos de la aplicación.
- Era razonable guardar los metadatos en una base de datos, y los archivos estáticos normalmente se almacenan en el sistema de archivos.
Uso de SQLite para servir archivos
- Clace decidió usar SQLite en lugar del sistema de archivos para almacenar los archivos de las apps.
- Esto permite cambios de versión atómicos, de modo que durante una actualización varios archivos pueden procesarse en una sola transacción.
- Al crear y actualizar apps, todos los archivos se suben a la base de datos SQLite, mientras que en modo de desarrollo se usa el sistema de archivos local.
Ventajas de usar SQLite
- Actualizaciones transaccionales: se pueden actualizar varios archivos a la vez, garantizando que no haya una webapp rota durante la actualización.
- Rollback de despliegues: si ocurre un error, el despliegue puede revertirse, y hacer rollback de una transacción de base de datos es más fácil que limpiar el sistema de archivos.
- Desduplicación de archivos entre versiones: aunque el mismo archivo exista en varias versiones, el contenido del archivo se almacena solo una vez.
- Desduplicación entre apps: evita duplicados cuando existen archivos idénticos entre varias apps.
- Facilidad de respaldo: usar SQLite permite respaldar fácilmente el estado del sistema.
- Hashing de contenido: al subir archivos se guarda el SHA del contenido para facilitar el caché del navegador.
- Compresión: el contenido de los archivos se almacena comprimido con Brotli, y puede guardarse fácilmente en varios formatos.
Rendimiento
- El enfoque de acceso a la base de datos SQLite de Clace ofrece un rendimiento sobresaliente.
- No se realizaron pruebas de benchmark directas porque no existe una implementación equivalente usando sistema de archivos.
- Según benchmarks del equipo de SQLite, en algunas cargas de trabajo SQLite puede ofrecer mejor rendimiento que el sistema de archivos.
Soporte multinodo
- Clace actualmente se ejecuta en un solo nodo.
- Cuando se agregue soporte multinodo, planean usar una base de datos Postgres compartida en lugar de SQLite local.
- Esto puede generar problemas de latencia, por lo que planean usar la base de datos SQLite local como caché de archivos para reducirla.
Por qué este enfoque no es común
- La mayoría de los servidores web usan el sistema de archivos por conveniencia.
- Es posible actualizar archivos con herramientas del sistema de archivos, mientras que usar una base de datos requiere una interfaz API para subir archivos.
Resumen de GN⁺
- Clace es una plataforma para desarrollar y desplegar herramientas internas, y maximiza las ventajas del almacenamiento de archivos usando SQLite.
- Al usar SQLite, ofrece diversas ventajas como actualizaciones transaccionales, rollback, desduplicación y facilidad de respaldo.
- Este enfoque no es común por la conveniencia e historia del sistema de archivos, pero mejora la eficiencia al aprovechar el rendimiento y las funciones de SQLite.
- Entre los proyectos con funciones similares se recomiendan Firebase y AWS Lambda.
1 comentarios
Comentarios de Hacker News
Hace unos años, inspirado por el artículo "35% Faster Than The Filesystem", hice un experimento para servir archivos estáticos usando SQLite. Creé un plugin para servir archivos estáticos desde SQLite mediante Datasette, pero no lo usé mucho. Si quieres servir archivos con SQLite, la herramienta CLI
sqlite-utils insert-filespuede ser útil.Las actualizaciones transaccionales son una ventaja importante porque permiten actualizar varios archivos a la vez. Ya sea que el servidor use SQLite o el sistema de archivos, eso no evita que la app web se rompa durante una actualización. Hay que asegurarse de que todos los subrecursos de la página se referencien usando un hash de contenido específico o un nombre de versión.
Cuando trabajaba en una pequeña empresa de desarrollo de videojuegos en 2011/2012, guardábamos todos los assets en una base de datos sqlite3 y creábamos archivos pak para almacenar los offsets de los archivos. Eso permitía cargar assets rápidamente en juegos móviles, y al guardar los metadatos en la base de datos era fácil encontrar archivos similares.
Hay una ventaja en poder consultar archivos usando SQLite en lugar del sistema de archivos. Las consultas SQL también pueden usarse con seguridad de tipos mediante Kysely.
La idea de servir contenido estático con SQLite no es perfecta. Los servidores web modernos usan estrategias óptimas para manejar archivos estáticos. SQLite ofrece soporte para I/O mapeada en memoria, pero no es adecuado para sitios web a gran escala.
SQLite es adecuado para sitios web con menos de 100K hits por día. El sitio web de SQLite maneja entre 400K y 500K solicitudes HTTP al día y, en la mayoría de los casos, el promedio de carga es inferior a 0.1.
Un CMS de generador de sitios estáticos puede usar una base de datos SQLite para desarrollar y actualizar un sitio web, y luego volcarlo al sistema de archivos como páginas estáticas para desplegarlo.
En computación científica de alto rendimiento, una de las formas más flexibles y de mayor rendimiento para acceder a los datos suele ser una base de datos SQLite de solo lectura en un ramdisk.
Sería interesante comparar este enfoque con casos en los que el sistema de archivos puede ofrecer deduplicación, snapshots, versionado y compresión. Con un sistema de archivos avanzado, quizá sea más fácil reemplazar un directorio por una nueva versión.
El enfoque de usar una base de datos como sistema de archivos tiene ventajas, pero cuando surgen problemas puede volverse una pesadilla.