- SQLite es muy rápido. Puede sostener simultáneamente ~168,000 lecturas y ~8000 escrituras en un servidor común single ~40€/m
- Como es una librería embebida diseñada para aplicaciones del lado del cliente, como sistemas embebidos, teléfonos y aplicaciones de escritorio, la base de datos SQLite debe estar ubicada junto al servidor de aplicaciones y no puede accederse a ella a través de la red
- ¿Uso de SQLite en situaciones donde se necesita más de una máquina?
- Un proyecto de fin de semana podría explotar en popularidad y necesitar escalar rápidamente
- Uno de los requisitos del CTO podría ser desplegar servicios de alta disponibilidad en al menos 2 centros de datos distintos
- En los últimos años han aparecido varios proyectos que intentan adaptar SQLite para convertirlo en una base de datos backend para aplicaciones backend.
- Un texto para averiguar si esto es un cambio de paradigma que permite a las organizaciones ofrecer una mejor experiencia de usuario más rápido, o si es puro hype de marketing impulsado por empresas que intentan inflar su "propuesta única de valor (Unique Selling Proposition)"
Usar SQLite como base de datos edge
- SQLite no se promociona como una simple base de datos backend, sino como una base de datos edge
- Los jugadores más representativos son Cloudflare D1, fly.io con LiteFS y Turso
- La mayoría de los derivados de SQLite funcionan de forma parecida
- Hay una base de datos principal que acepta escrituras en algún lugar, y esta se replica de forma asíncrona hacia otras regiones
- La replicación suele hacerse transmitiendo el registro de todas las transacciones ejecutadas en la base de datos, es decir, el Write-Ahead Log de SQLite
- En esta arquitectura, en teoría las lecturas pueden atenderse desde centros de datos edge, pero las escrituras todavía tienen que enviarse a una ubicación central
- En la práctica, nadie quiere que un cliente complete un pedido en una aplicación de e-commerce, que el pedido quede aprobado en la base de datos principal de SQLite, pero que luego el réplica de lectura regional esté retrasado y todavía no haya recibido los datos actualizados, mostrando un mensaje de error de que no se encontró
- Bienvenidos al "doloroso mundo de la consistencia eventual"
La solución de LiteFS y sus límites
- LiteFS propone una solución medio hacky. La aplicación configura una cookie
__txidpara rastrear la última transacción que tiene la réplica regional y, si está demasiado desactualizada, reenvía las consultas de lectura a la base de datos principal. - Ahora la aplicación queda fuertemente acoplada a la base de datos y al proxy inverso
- LiteFS no menciona que solo soporta alrededor de 100 escrituras por segundo
Principales desventajas de la mayoría de los sistemas SQLite distribuidos
- La mayoría de los sistemas SQLite distribuidos no soportan transacciones interactivas que realicen algunos cálculos entre distintas consultas de una misma transacción.
- Solo puede haber una transacción de escritura activa a la vez. En una base de datos SQLite normal esto suele estar bien, porque la mayoría de las escrituras no duran más de unas decenas de microsegundos
- Pero si introduces latencia de red entre la aplicación y la base de datos SQLite, el sistema se rompe. La base de datos queda bloqueada durante el tiempo de ida y vuelta de la transacción y terminará limitada a unas pocas escrituras por segundo
- Turso lo "resuelve" con batching. Puede agrupar varias consultas en un lote para ejecutarlas como una sola transacción. Cloudflare D1 "resuelve" el problema con lotes y procedimientos almacenados
¿Y si hubiera una solución más simple?
- Para las aplicaciones web ya existe una forma muy simple y poderosa de volverlas muy rápidas a nivel global: el caché HTTP usando encabezados
Cache-ControlyETag - Usar caché HTTP evita tener que recurrir a técnicas similares a las de una base de datos de consistencia débil, lo que impide que la aplicación web se vuelva demasiado compleja o vulnerable a condiciones de carrera
- El autor de este texto dedica bastante tiempo en su nuevo libro "Cloudflare for Speed and Security" a explicar distintas estrategias de caché que no solo hacen rápidas las aplicaciones web, sino que también permiten manejar muchos usuarios concurrentes con recursos mínimos
La base de datos como abstracción
- La latencia no era el único problema que el SQLite distribuido intentaba resolver. El otro era la complejidad operativa.
- Gestionar un clúster de servidores conectados por red es difícil y a menudo termina en caídas y pérdida de ingresos. Ni hablar de la administración de bases de datos, que requiere gestión constante y una excelente cultura de seguridad para evitar desastres como el que sufrió GitLab en 2017.
- Entonces la idea es empaquetar la base de datos junto con la aplicación y poner todo en un solo servidor
- Eso está bien cuando hay un solo desarrollador, pero en organizaciones grandes probablemente haya personas o equipos dedicados al mantenimiento de los servidores de base de datos
- Esa es precisamente la razón por la que una base de datos a la que se accede por sockets, y no una librería embebida, es una gran abstracción: en realidad no es una abstracción técnica sino organizacional. En desarrollo puede ser un contenedor simple ejecutándose en la máquina del desarrollador, pero en producción puede ser cualquier cosa, desde un contenedor corriendo en el mismo servidor que la aplicación hasta un clúster distribuido accesible por red. El desarrollador solo tiene que cambiar una única variable de configuración,
DATABASE_URL, y el equipo de operaciones se encarga de todo lo demás - En cambio, el sistema de archivos tradicional de Unix no era una abstracción adecuada para la computación distribuida. Claro que existe NFS (Network File System), pero como el sistema de archivos Unix fue diseñado para acceso desde una sola máquina, su rendimiento no es particularmente bueno. En cambio, el protocolo S3 es una muy buena abstracción para almacenar grandes volúmenes de datos no estructurados de forma eficiente, escalable y confiable. El desarrollador solo usa un SDK compatible con S3 y se olvida; el equipo de operaciones o el proveedor cloud se encargan del rendimiento, la durabilidad, la confiabilidad y todo lo demás
Conclusión
- SQLite es realmente una base de datos asombrosa, pero para la mayoría de los equipos conviene evitar SQLite y elegir PostgreSQL en su lugar
- Se han invertido innumerables horas de ingeniería en convertir PostgreSQL en la mejor base de datos backend. Si eliges SQLite, inevitablemente tendrás que reinventar de forma frágil y con bugs cosas que PostgreSQL ya tiene desde hace mucho tiempo
- En este momento, el impulso por convertir SQLite en una base de datos backend parece no ser más que un golpe de marketing por parte de empresas que venden infraestructura de edge computing y que se dieron cuenta de que la computación no es nada sin almacenamiento de datos. Mi consejo (no solicitado) para ellas es invertir en caché HTTP en lugar de construir un CDN e imponer complejidad a las aplicaciones. Eso da resultados mucho mejores
- Debido a la complejidad que se introduce, el 99.9% de las aplicaciones backend no verá ninguna ventaja en moverse al edge y, en cambio, debería enfocarse en desplegar buenas estrategias de caché para ofrecer una gran experiencia global por debajo de 100 ms
- Y aquí es donde termina el experimento de SQLite para aplicaciones del lado del servidor. Victoria para PostgreSQL
-
"Los amateurs discuten táctica, los profesionales discuten logística. (Amateurs discuss tactics. Professionals discuss logistics.)"
Es decir, que para el éxito importan más los sistemas y procesos de soporte que hacen posibles esas decisiones, es decir, la logística y la gestión, que las decisiones tácticas tomadas sobre el terreno
Opinión de GN⁺
- Tal como sostiene el autor, usar SQLite en la mayoría de las aplicaciones backend parece solo aumentar la complejidad sin aportar beneficios reales. Usar una base de datos ya probada y madura como PostgreSQL probablemente sea una mejor opción.
- El empuje de los proveedores de infraestructura edge por SQLite parece ser más una estrategia de marketing que una ventaja técnica real. Les sería más útil a los desarrolladores de aplicaciones que invirtieran más en caché HTTP y CDN.
- La mayoría de las aplicaciones backend pueden ofrecer servicios suficientemente rápidos y escalables con una estrategia de caché adecuada. A menos que el edge computing sea realmente necesario, conviene evitar complejidad excesiva.
- SQLite distribuido puede ser útil en ciertos casos de uso específicos, pero todavía parece tener límites para usarse como solución general. No será fácil satisfacer al mismo tiempo la comodidad de desarrollo, el rendimiento y la consistencia
- Al final, lo más importante es elegir la tecnología que se ajuste a los requisitos de la aplicación y a la capacidad del equipo. En vez de dejarse llevar por la moda, conviene analizar a fondo pros y contras y tomar la decisión con cuidado.
- El autor enfatiza que SQLite todavía tiene muchas carencias para usarse como base de datos backend, pero eso no significa que haya que descartarlo por completo, ya que podría haber otros casos de uso donde sí se puedan aprovechar sus ventajas.
3 comentarios
Más que preguntarse cuál es mejor entre Postgres y sqlite,
¿no sería mejor pensar cuál de los dos encaja mejor con tu situación?
Al final, lo óptimo cambia según el contexto.
Opiniones de Hacker News