Redis se usa principalmente como un caché de aplicaciones o una base de datos de respuesta rápida. Pero un momento… puedes crear un caché en una base de datos relacional de la siguiente manera:
CREATE TABLE cache(
`key` VARCHAR(64) PRIMARY KEY,
value VARCHAR(255) NOT NULL,
last_updated TIMESTAMP
DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP
);
Además, con MariaDB, puedes elegir entre los muchos motores de almacenamiento disponibles. Por ejemplo, si deseas almacenar la tabla cache en memoria, simplemente usa el motor de almacenamiento MEMORY:
CREATE TABLE cache(
...
) ENGINE=MEMORY;
Cuando configuras la tabla cache para usar el motor de almacenamiento MEMORY, sus datos residirán completamente en RAM. Esto es similar a cómo opera Redis manteniendo los datos en memoria para acceso de baja latencia. Esto suena muy bien y definitivamente tiene sus beneficios. Sin embargo, hay algunos detalles que vale la pena explorar.
Caso de Uso de Ejemplo#
Supongamos que tienes una aplicación web que necesita rastrear IDs de sesión. Usar una tabla MEMORY de MariaDB parece ser una buena idea aquí ya que hay potencial para reducir la carga en tus bases de datos primarias y mejorar los tiempos de respuesta para tus usuarios. Aquí está un ejemplo de cómo podrías implementar dicho caché usando el motor de almacenamiento MEMORY:
CREATE OR REPLACE TABLE users_cache (
user_name VARCHAR(50) NOT NULL PRIMARY KEY REFERENCES users(id),
session_id VARCHAR(50),
last_updated DATETIME NOT NULL
DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP
) ENGINE=MEMORY;
Típicamente, la inserción en esta tabla ocurriría cada vez que un usuario inicia sesión. Pero generalizando un poco más, la inserción en un caché podría ocurrir cada vez que lees datos almacenados en tablas basadas en disco. Usaremos este último enfoque y asumiremos que almacenar los IDs de sesión permanentemente es un requisito del negocio solo para poder hacer más experimentos. En cualquier caso, puedes configurar una tarea en segundo plano para actualizar este caché periódicamente o invalidarlo cuando los datos subyacentes cambien.
Invalidez y Manejo del Caché#
Hay varias maneras de manejar la invalidación del caché con MariaDB. Por ejemplo, puedes establecer una duración máxima para cada fila (a través de una columna para el tiempo de expiración) y usar event schedulers para borrar o actualizar los datos en caché a intervalos fijos. El siguiente es un ejemplo:
CREATE OR REPLACE EVENT ev_remove_stale_user_cache_entries
ON SCHEDULE EVERY 20 MINUTE DO
DELETE FROM users_cache
WHERE NOW() > last_updated + INTERVAL 2 HOUR;
Para realizar pruebas, puedes usar intervalos más cortos. Por ejemplo, EVERY 1 SECOND y INTERVAL 20 SECOND. Además, recuerda habilitar el event scheduler de MariaDB configurando la propiedad event_scheduler o para pruebas, ejecutando:
SET GLOBAL event_scheduler = ON;
Si deseas probar esto, puedes encontrar un ejemplo completo en GitHub. O mira el video corto que muestra el ejemplo en acción.
Pros y Contras#
Aunque usar el motor de almacenamiento MEMORY puede acelerar tiempos de recuperación de datos, como siempre, depende del caso de uso exacto: Prueba esta configuración con tus aplicaciones antes de tomar decisiones. En particular, es importante tener en cuenta que MEMORY realiza bloqueos de tabla completos. Esto significa que podría no ser adecuado cuando necesitas actualizar el caché con más frecuencia de lo que lo lees. En otras palabras, usar el motor de almacenamiento MEMORY es una buena opción para datos que necesitan ser accedidos con frecuencia y actualizados infrecuentemente.
Una ventaja clave al usar el motor MEMORY es cuando tu aplicación necesita mezclar datos de caché con datos en tablas de una base de datos relacional, por ejemplo, durante una solicitud HTTP individual. Imagina una aplicación que procesa actualizaciones de información del usuario. Cada actualización podría involucrar la escritura en un caché y la actualización simultánea de un registro relacional. Esto requeriría dos accesos diferentes a dos bases de datos diferentes. Con MariaDB, puedes manejar esto en una sola base de datos usando SQL. Esto elimina la sobrecarga y la complejidad de gestionar almacenes de datos separados y coordinarlos entre ellos. Aquí tienes un ejemplo simplificado de cómo podría verse una operación de este tipo:
SET @data = "other data";
UPDATE users SET data = @data WHERE id = 123;
REPLACE INTO users_cache (user_id, data) VALUES (123, @data);
En este ejemplo, las columnas data en la tabla users como en la tabla user_cache se actualizan en una sola llamada a la base de datos. Ten en cuenta que el motor de almacenamiento MEMORY no es transaccional, lo cual no es tan importante si lo comparas con un caché que vive en una tecnología de base de datos completamente diferente a la de tu base de datos operativa.
Una ventaja adicional y obvia pero importante al usar el motor MEMORY es que puedes eliminar de tu aplicación lógica políglota de persistencia. Si tu equipo de trabajo ya está familiarizado con SQL, MariaDB proporciona una experiencia más sencilla y directa sin la necesidad de tener que aprender nuevas sintaxis o manejar otro stack de tecnología.
¿Cómo se compara con Redis?#
Si bien Redis es una herramienta poderosa para manejar estructuras de datos simples como cadenas, hashes, listas, conjuntos y conjuntos ordenados directamente en memoria, el motor MEMORY de MariaDB maneja consultas complejas de manera más natural porque soporta todo el poder de SQL y los sistemas de bases de datos relacionales. Esto significa que puedes realizar uniones, subconsultas e incluso transacciones complejas, lo que no es tan sencillo en Redis.
Ahora, también está la cuestión de la escalabilidad, especialmente la escalabilidad horizontal. Esto implica agregar más nodos a un sistema para distribuir la carga y aumentar la capacidad sin interrumpir el servicio. Tanto Redis como MariaDB ofrecen soluciones robustas, pero sus mecanismos son diferentes.
Redis logra la escalabilidad horizontal principalmente a través de sharding, donde los datos se particionan en múltiples instancias de Redis. Esto puede configurarse manualmente o gestionarse a través de Redis Cluster, que maneja el sharding y proporciona alta disponibilidad mediante procesos de failover y replicación. Redis Cluster soporta hasta 1000 nodos, lo que le permite escalar masivamente. Este modelo es particularmente efectivo para aplicaciones que requieren operaciones ultrarrápidas y alto rendimiento en estructuras de datos simples.
MariaDB ofrece un enfoque algo similar para la escalabilidad. Y probablemente lo adivinaste: Se logra a través de un motor de almacenamiento. El motor Spider particiona los datos de la tabla en múltiples nodos de MariaDB, tratándolos como una sola entidad lógica. Esto permite consultar y actualizar datos en varios servidores físicos de manera fluida, como si estuvieran en un solo servidor local. El motor Spider soporta SQL y operaciones de datos transaccionales, por lo que puedes ejecutar consultas complejas cuando lo necesites. Es útil para entornos de bases de datos grandes donde la distribución de datos es esencial para el rendimiento y para satisfacer las demandas de aplicaciones a gran escala.
Durabilidad y Persistencia#
Una diferencia a considerar es que el motor de almacenamiento MEMORY en MariaDB no ofrece persistencia de datos después de reinicios del servidor. Los datos almacenados en tablas MEMORY son volátiles; los datos se borran cuando la base de datos se reinicia, de manera similar a como occurre con Redis en su configuración predeterminada. Si la persistencia es crucial, podrías considerar usar los motores de almacenamiento Aria o InnoDB de MariaDB para el caché. De hecho, InnoDB tiene un excelente rendimiento, gracias a su mecanismo de caché, que reduce la carga en los nodos primarios.
Reflexiones Finales#
Cambiar de Redis a MariaDB como solución de caché podría no ser adecuado para todos los proyectos, pero es una opción viable para aquellos que buscan simplificar su stack de tecnología o aprovechar experiencia existente en SQL. El motor MEMORY proporciona una manera fácil de implementar soluciones de caché con herramientas que ya conoces y reduce la sobrecarga de gestionar sistemas adicionales. Además, para aquellos que buscan un término medio, MariaDB también puede servir como una capa de caché complementaria junto con Redis, aprovechando las fortalezas de ambos sistemas. Además, puedes aprovechar Redis como caché para MariaDB MaxScale.
Prueba MariaDB y configura tu propio caché en memoria con el motor de almacenamiento MEMORY. Experimenta cómo se adapta a tu conocimiento existente de SQL. He creado un archivo de texto simple con instrucciones detalladas y código que puedes ejecutar para ver el caché en acción usando solo SQL. ¡Todo lo que necesitas es conectarte a tu servidor MariaDB (inicia uno rápidamente usando Docker si no tienes uno en funcionamiento) y ejecutar los comandos en cualquier cliente SQL compatible con MariaDB (la mayoría lo son)! Aquí puedes ver un demo en acción:
Si tienes preguntas o quieres compartir tu experiencia, no dudes en unirte al Slack de la Comunidad de MariaDB y cuéntanos sobre tu caso.