Redis como caché o como base de datos

Redis guarda los datos en la RAM, y por eso es tan rápido. Esa misma característica genera la duda más común sobre él: si la memoria se borra cuando el proceso se detiene, ¿se puede confiar en Redis para guardar datos de verdad?

Depende del papel que cumpla en tu aplicación. Como caché, perder los datos es aceptable. Como base de datos, no lo es, y entonces tienes que configurar la persistencia en disco. Para la visión general de la herramienta, mira qué es Redis.

¿Cuál es la diferencia entre usar Redis como caché y como base de datos?#

La pregunta que separa los dos usos es: si este dato desaparece, ¿puedo recrearlo?

• Caché: el dato es una copia de algo que ya existe en otra base de datos o se puede recalcular. Si desaparece, la aplicación lo busca de nuevo en el origen. Redis solo acelera.
• Base de datos: el dato solo existe en Redis (sesiones, colas, contadores, rankings). Si desaparece, se pierde para siempre.

¿Cómo usar Redis como caché?#

El patrón más común es cache-aside: la aplicación consulta primero la caché y solo cuando no encuentra el dato (miss) va a la base de datos y guarda el resultado con un plazo de validez.

// npm install ioredis pg
import { Redis } from "ioredis";
import pg from "pg";

const redis = new Redis(process.env.REDIS_URL);
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });

export async function getUser(id) {
  const key = `user:${id}`;

  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached); // hit

  const { rows } = await pool.query("SELECT id, name FROM users WHERE id = $1", [id]);
  if (rows.length === 0) return null;

  await redis.set(key, JSON.stringify(rows[0]), "EX", 60); // expira en 60 s
  return rows[0];
}

Dos puntos pesan más que el código:

1. Toda caché necesita TTL. El EX 60 hace que la clave expire en 60 segundos. Sin plazo, la caché se vuelve una copia vieja que nadie invalida. Detalles del comando en EXPIRE.
2. Cuando el dato cambia en la base de datos, invalida la clave (redis.del(key)) o acepta que la caché quede desactualizada hasta que termine el TTL.

Como la caché es desechable, la persistencia puede quedar desactivada. La propia documentación de Redis menciona el modo sin persistencia como una configuración que a veces se usa en cachés.

¿Qué pasa cuando la caché llena la memoria?#

El límite de memoria solo existe si lo configuras. La directiva maxmemory define el tope, y maxmemory-policy define qué hacer al alcanzarlo:

redis-cli CONFIG SET maxmemory 256mb
redis-cli CONFIG SET maxmemory-policy allkeys-lru

Sin maxmemory, en sistemas de 64 bits el límite es cero, es decir, sin tope: Redis sigue creciendo hasta agotar la memoria disponible en la máquina o en el contenedor. Las políticas más usadas, según la documentación oficial:

• noeviction: no expulsa nada y devuelve un error en los comandos que agregan datos. Los comandos de lectura siguen funcionando.
• allkeys-lru: expulsa las claves usadas hace más tiempo. La documentación la recomienda como buena opción por defecto cuando pocas claves reciben la mayor parte de los accesos.
• allkeys-lfu: expulsa las claves con menos accesos.
• volatile-lru, volatile-ttl y variantes: solo expulsan claves que tienen TTL. Si ninguna clave tiene expiración, se comportan como noeviction.

Para caché pura, allkeys-lru es el punto de partida. Para Redis como base de datos, usa noeviction: un error de memoria llena es mejor que borrar datos en silencio.

¿Cómo guarda Redis los datos en disco?#

Hay dos formas de persistencia, que puedes usar por separado o juntas, según la documentación de persistencia.

RDB: fotos periódicas#

RDB guarda una foto del conjunto de datos en un archivo (dump.rdb) a intervalos definidos. Esta regla guarda cada 60 segundos si cambiaron al menos 1000 claves:

save 60 1000

El archivo es compacto, sirve bien para copias de seguridad y acelera el reinicio de Redis con bases grandes. El costo: si el proceso cae sin un apagado limpio, pierdes lo escrito desde la última foto, en general algunos minutos.

AOF: registro de cada escritura#

AOF (append-only file) agrega cada comando de escritura a un log, que se reproduce al arrancar para reconstruir los datos. Para activarlo:

appendonly yes

La durabilidad depende de la política appendfsync:

AOF suele generar archivos más grandes que RDB y, según la política de fsync, puede ser más lento. Redis reescribe el log en segundo plano para que no crezca sin parar.

¿RDB, AOF o ambos?#

La documentación de Redis lo resume así:

• Si quieres una seguridad de datos comparable a la de una base como PostgreSQL: usa ambos.
• Si puedes aceptar perder algunos minutos en caso de desastre: RDB solo es suficiente.
• AOF solo es común, pero la documentación lo desaconseja, porque un RDB de vez en cuando ayuda con las copias, con reinicios más rápidos y en caso de bugs en el motor de AOF.

Con ambos activos, Redis reconstruye los datos desde el AOF al reiniciar, porque es el más completo.

¿Cuándo usar cada modo?#

Usa Redis como caché cuando:

• el origen de los datos es otra base de datos y la consulta allí es lenta o costosa;
• el dato puede estar algunos segundos desactualizado;
• perder toda la caché solo causa lentitud temporal, no errores.

Usa Redis como base de datos cuando:

• el dato vive naturalmente en memoria y se lee rápido: sesiones, colas, contadores, limitación de tasa, rankings;
• aceptas la ventana de pérdida de la persistencia elegida;
• todo el conjunto cabe en la RAM con margen.

Prefiere otra base de datos cuando el dato es relacional, necesita consultas complejas o no puede perder ni un segundo de escrituras. En ese caso, mira qué base de datos elegir.

Se pueden mezclar los dos papeles en una instancia, pero la documentación sugiere separarlos en dos instancias cuando sea posible: una caché con expulsión de claves y un Redis persistente sin expulsión.

¿Persistencia es lo mismo que copia de seguridad?#

No. La persistencia hace que Redis sobreviva a un reinicio en el mismo disco. Si pierdes el disco o la máquina, los archivos se pierden con ellos, así que igual necesitas copias fuera de la máquina. El archivo RDB es seguro de copiar con el servidor en marcha, porque nunca se modifica una vez terminado. La guía de cómo hacer un backup de una base de datos cubre la rutina completa.

Cómo hacerlo en Square Cloud#

Square Cloud ofrece hosting de Redis desde el plan Standard, con persistencia. Creas la base en el panel y queda lista en segundos en el mismo datacenter que las aplicaciones, con una latencia media de cerca de 1 ms. La conexión usa TLS obligatorio (rediss://, con el certificado descargado del panel). El plan Hobby no incluye hosting de bases de datos.

Como Redis guarda todo en la RAM, el tamaño del conjunto de datos define cuánta memoria le asignas, desde 512 MB. Para caché, dale un TTL a cada clave, como en el ejemplo anterior, para que el conjunto de datos no crezca sin tope. Hay una única base de datos lógica, así que separa caché y datos permanentes por prefijo de clave. Usa también un cliente que se reconecte solo, porque los clientes inactivos se desconectan tras 5 minutos.

Puedes tomar snapshots manuales cuando quieras, y todo plan que incluye bases de datos tiene también un snapshot automático diario. Un snapshot se puede restaurar en la misma base, en otra del mismo motor o en una base nueva, o descargar como .zip. Mira hosting de Redis y snapshots.