Redka - Redis reimplementado con SQLite

• Redka busca reimplementar las ventajas de Redis sobre SQLite, manteniendo compatibilidad con la API de Redis
• Características principales:
  • Los datos no necesitan ajustarse al tamaño de la RAM
  • Soporte para transacciones ACID
  • Consultas de datos y capacidades de reporting mejoradas mediante vistas SQL
  • Soporta tanto servidor in-process (API de Go) como servidor standalone (RESP)
  • Soporte para comandos y protocolo compatibles con Redis
• Actualmente está en desarrollo; para el estado de soporte y la hoja de ruta, consulta la documentación a continuación

Comandos soportados

• Redka tiene como objetivo soportar los 5 tipos de datos principales de Redis: String, List, Set, Hash y Sorted Set
• String, Hash, gestión de claves y comandos de transacción ya están soportados; List, Set y Sorted Set están en desarrollo
• Para la lista detallada de comandos, consulta el original

Instalación

Servidor standalone

• Descarga el archivo binario correspondiente a tu sistema operativo desde la página de releases y ejecútalo
• Si usas Docker, descarga la imagen con docker pull nalgeon/redka

Módulo de Go

• Instala el módulo con go get github.com/nalgeon/redka
• Usa github.com/mattn/go-sqlite3 o modernc.org/sqlite como driver de SQLite

Cómo usarlo

Servidor standalone

• Ejecuta el binario descargado con el formato redka [-h host] [-p port] [db-path]
  • Los valores por defecto son host localhost, puerto 6379 y sin ruta de DB (en memoria)
• Si usas Docker, ejecútalo con el comando docker run. Para opciones detalladas, consulta el original
• Después de iniciar el servidor, puedes conectarte con clientes compatibles con Redis como redis-cli, redis-py o go-redis

Servidor in-process

• Crea el objeto DB con la función redka.Open(). Es obligatorio importar el driver
• Ejecuta distintos comandos invocando los métodos del objeto redka.DB
• Maneja transacciones con los métodos View (solo lectura) y Update (con escritura)

Persistencia

• Redka almacena datos en la base de datos SQLite usando las tablas rkey, rstring y rhash
• Es posible consultar datos con SQL mediante vistas para cada tipo de dato (vstring, vhash, etc.)

Rendimiento

• Comparación de rendimiento entre Redis y Redka con la herramienta redis-benchmark
  • Redka es unas 6 veces más lento en SET y alrededor de 2 veces más lento en GET
  • Aun así, muestra un rendimiento de unas 23K escrituras/s y 57K lecturas/s
• Si se ejecuta en un contenedor, puede haber degradación de rendimiento

Hoja de ruta

• Para el lanzamiento 1.0, se planea implementar principalmente las funciones clave de la era de Redis 2.x
  • String, Hash, gestión de claves y soporte de transacciones ya están completos
  • Sorted Set está en desarrollo
  • List y Set están planeados
• En versiones futuras se planea agregar tipos de datos como Stream, HyperLogLog y Geo, además de funciones Pub/Sub
• No hay planes de implementar scripting en Lua, autenticación/ACL, multi-DB, Watch/Unwatch, etc.
• Tampoco se planea implementar funciones de cluster ni Sentinel

Opinión de GN⁺

• El enfoque de Redka, que ofrece persistencia mientras mantiene compatibilidad en gran parte con Redis, resulta interesante. El soporte para transacciones ACID también parece una ventaja.
• En rendimiento no alcanza a Redis, pero si se necesita persistencia, parece una alternativa que vale la pena considerar.
• Aun así, como todavía está en una etapa temprana de desarrollo, habrá que seguir observando su estabilidad, y el hecho de que falten varias funciones en la hoja de ruta es algo a considerar para una adopción real.
• Para uso in-memory, al final no podrá superar a Redis, pero como capa de persistencia basada en SQLite podría resultar útil.
• Últimamente ha aumentado la demanda de stacks ligeros en entornos de edge computing, así que en ese tipo de escenarios podría probarse Redka en lugar de Redis.

[yangeok]

Parece que sería útil usarlo cuando el scheduler necesita conectarse a Redis jaja

[GN⁺]

Comentarios en Hacker News

• Hay cierta reflexión sobre hasta qué punto seguir el modelo de Redis de "todo serializado en un solo hilo", sin concurrencia
• Se puede obtener mejor rendimiento de SQLite usando su biblioteca de bajo nivel, activando WAL, usando una conexión por cada goroutine de lectura y enviando lotes de escritura a través de un canal/cola con búfer hacia un hilo escritor dedicado
• Con esto, se puede desactivar el mutex integrado por conexión de SQLite y aun así mantener la seguridad de hilos, ya que cada conexión se usa solo desde un hilo a la vez
• Usar buffers grandes estilo arena, como copiar en un búfer los bytes de parámetros que llegan desde solicitudes/sockets de red o copiar directamente desde SQLite al socket, puede ahorrar mucho tiempo al reducir asignaciones y transferencias individuales de cadenas
• Son consejos que salen de la experiencia de intentar obtener el máximo rendimiento de escritura de SQLite desde Go
• Me gustan tanto Redis como SQLite, así que decidí combinar ambos. SQLite está especializado en muchas consultas pequeñas, así que parece encajar bien, ya que un motor relacional puede acercarse a Redis tanto como sea posible
• Estoy esperando a que alguien reemplace la máquina de estados de TigerBeetle para implementar la API de Redis
• Sería bueno tener una alternativa a Redis donde no haya que pensar si el conjunto de datos cabe en memoria o no
• Toda la propuesta de valor de Redis es funcionar en memoria y ofrecer rendimiento de memoria. Si se pasa a disco, casi no hay razón para usar Redis
• Cuando se agrega I/O de red, gran parte del fantástico rendimiento de Redis desaparece. Si se usa un servicio SaaS de Redis hospedado, el rendimiento recibe un golpe grande. Si fuera más fácil ejecutar un almacén clave/valor compatible con Redis en tu propio clúster, eso sería una ventaja
• Me pregunto si esto o Garnet soporta más comandos de Redis. Quiero integrar en un programa un subconjunto de funcionalidad compatible con Redis para fines de depuración local, y hay una API en medio que puede proteger contra comandos de Redis no soportados
• Cuando Foursquare hizo famoso a MongoDB, alguien publicó un PoC de una base de datos NoSQL implementada sobre MySQL, pero no se volvió tendencia. Aun así, hace pensar cuánto rendimiento hemos sacrificado para no tener que reinventar SQL cada vez que necesitamos una BD. Me gustan experimentos como este y a veces terminan convirtiéndose en proyectos nuevos
• Uso Redis como una capa de caché delante de la BD. No entiendo este concepto
• Pero, dicho esto, aunque usa SetMaxConnections(1), en modo WAL (que está usando) SQLite soporta escrituras que no bloquean lecturas, así que permitir concurrencia de lectura podría aportar ventajas