Rearquitectura: migración de Redis a SQLite

Contexto

• Wafris es una empresa de firewall de aplicaciones web de código abierto que ofrece un cliente de middleware para Rails
• El cliente v1 inicial requería un almacén de datos Redis local, pero ahora lanzó un cliente v2 que usa SQLite
• Este artículo trata sobre el proceso de decisión para migrar de Redis a SQLite, las consideraciones de rendimiento y los cambios de arquitectura

Resumen

• SQLite, Redis y los RDBMS tradicionales (Postgres/MySQL) tienen cada uno ventajas y desventajas
• Estos almacenes de datos no son intercambiables entre sí, y tratar de hacerlo puede causar problemas
• Este artículo explica el proceso de reconstrucción del cliente v1 basado en Redis hacia un cliente v2 basado en SQLite

¿Qué forzó este cambio?

• El objetivo de Wafris es permitir que los desarrolladores protejan sus sitios fácilmente
• El cliente v1 usaba un almacén de datos Redis, pero muchos usuarios tuvieron problemas al desplegar Redis
• Se cambió a SQLite para reducir la carga de tener que convertirse en administrador de Redis

¿Qué es la velocidad?

• Redis es rápido en comparación con los RDBMS tradicionales, pero aun así hay muchos elementos que administrar
• En entornos en la nube, la latencia de red se vuelve un problema importante
• SQLite puede ofrecer un rendimiento más rápido al reducir los tiempos de ida y vuelta por la red

Suposiciones monolíticas

• Muchas aplicaciones distribuidas generan problemas al usar Redis
• Se replanteó la arquitectura para reducir la complejidad del uso de Redis

Adopción de SQLite

• SQLite reduce los cuellos de botella de IO de red
• SQLite compite con abrir archivos (fopen()), no con bases de datos cliente/servidor

Benchmarking de SQLite y Redis

• SQLite es aproximadamente 3 veces más rápido que Redis en ciertos casos de uso
• Incluso sin considerar la latencia de red, SQLite es más rápido

Lo que falta en los gráficos

• Incluso si el rendimiento de SQLite fuera peor en los benchmarks, en entornos reales puede ser más rápido debido a la latencia de red
• SQLite facilita la escalabilidad horizontal y reduce la carga de instalación y configuración para el usuario

Construcción de una arquitectura de sincronización

• En v1 (Redis), cuando el usuario actualizaba las reglas, estas se actualizaban en el almacén de datos Redis
• En v2 (SQLite), el cliente revisa periódicamente si hay reglas actualizadas y descarga una nueva base de datos SQLite

Arquitectura distribuida con SQLite

• El problema de los cuellos de botella de la base de datos se resuelve sincronizando la DB de SQLite en cada instancia de cómputo

Conclusión

• La arquitectura v2 basada en SQLite ayuda a que muchos sitios resistan ataques y permanezcan en línea
• Genera menos carga para el usuario y ofrece una Internet más segura y reforzada en seguridad

Resumen de GN⁺

• Este artículo explica el proceso y las razones para migrar de Redis a SQLite
• SQLite mejora el rendimiento al reducir la latencia de red y disminuye la carga de instalación y configuración para el usuario
• La arquitectura distribuida de SQLite resuelve los problemas de cuellos de botella de la base de datos
• El artículo ofrece una perspectiva sobre cómo desplegar un firewall de aplicaciones web de forma sencilla y hacerlo funcionar rápidamente

[GN⁺]

Opiniones de Hacker News

• Me interesa un modelo en el que cada servidor de aplicaciones copia un archivo de base de datos SQLite y lo reemplaza periódicamente

  • Se usa para reglas de firewall de aplicaciones web
  • También podría usarse para la configuración de feature flags
  • No pasa nada si las feature flags tardan unos segundos en actualizarse

• La latencia de lectura/escritura de Redis es proporcional a la cantidad de claves consultadas

  • Una app monolítica que usaba Postgres y Redis funcionó bien
  • Redis es de un solo hilo, así que una función de lectura masiva puede ralentizar otras tareas
  • Redis es bueno para leer y escribir una clave o un conjunto pequeño y fijo de claves
  • Fue interesante que SQLite tuviera buen rendimiento comparado con una instancia local de Redis

• El dataset parece tener 1.2 millones de elementos, pero en realidad no es grande

  • Las direcciones IPv4 ocupan 4.8MB, y con compresión simple podrían ocupar menos
  • Si Ruby soporta mmap, sería mejor usar directamente la lista de IP

• En un hackatón interno de Neon, escribieron un servidor en Node.js que convierte el protocolo de Redis en consultas de Postgres

  • Fue un proyecto de hacking divertido

• En RailsWorld 2023 había un ambiente negativo hacia Redis

  • Se daba por hecho que hacía falta un servidor Redis
  • Como tengo poca experiencia usando Redis, me pregunto si el ecosistema actual está en contra de Redis

• SQLite parece un caso de uso de nicho que funciona bien del lado del servidor sin replicación

  • Otra alternativa sería usar archivos estáticos cargados en memoria
  • SQLite es una buena alternativa

• Existe un proyecto llamado Redka que implementa Redis sobre SQLite

• La mejor cita: "SQLite no compite con las bases de datos cliente/servidor. SQLite compite con fopen()."

• Redis es rápido frente a un RDBMS tradicional, pero requiere administración

  • Todas las bases de datos requieren cierto nivel de administración
  • Si no te preocupan los joins, insertar y consultar filas también es muy rápido

• Hacer benchmarking es un arte oscuro para engañarte con números extremadamente precisos