Comparación de las Compensaciones de Rendimiento entre Persistencia AOF y RDB

La persistencia en Redis es un equilibrio entre cuántos datos puedes permitirte perder y cuánto trabajo de disco puede absorber tu servidor. Sin embargo, cuando la persistencia está habilitada—permitiendo que los datos se guarden en disco para su recuperación después de un reinicio—los desarrolladores deben elegir un mecanismo. Los dos métodos principales de persistencia en Redis son Snapshotting (RDB) y el Archivo de Solo Anexión (AOF). Comprender las implicaciones de rendimiento, las características de durabilidad y las compensaciones de configuración de cada uno es crucial para ajustar Redis a requisitos específicos de la aplicación en cuanto a velocidad frente a seguridad de datos.

Las instantáneas RDB son compactas y rápidas de cargar. AOF registra las escrituras con más frecuencia y generalmente ofrece mejores puntos de recuperación, pero cuesta más E/S de disco.

Entendiendo la Persistencia de Redis

Redis almacena todo su conjunto de datos en memoria volátil. Los mecanismos de persistencia son necesarios para mover estos datos al disco, de modo que Redis pueda recargar el conjunto de datos al reiniciar, asegurando la disponibilidad de los datos ante interrupciones del servicio o reinicios. Tanto RDB como AOF logran este objetivo mediante enfoques fundamentalmente diferentes, lo que resulta en perfiles de rendimiento distintos.

1. Instantáneas de la Base de Datos de Redis (RDB)

RDB crea una instantánea compacta y puntual de todo el conjunto de datos en intervalos especificados. Guarda estos datos en un archivo binario (dump.rdb).

Cómo Funciona RDB y su Impacto en el Rendimiento

La persistencia RDB depende en gran medida del comando BGSAVE (Guardado en Segundo Plano). Cuando se activa un guardado:

Forking: Redis bifurca el proceso principal en un proceso hijo.
Instantánea: El proceso hijo escribe todo el conjunto de datos en el archivo RDB en el disco.
Hilo Principal No Afectado (Mayormente): El hilo principal de Redis continúa atendiendo las solicitudes de los clientes sin ser bloqueado durante la operación de escritura, ya que el hijo maneja la E/S del disco.

Consideraciones de Rendimiento:

Latencia de Escritura: Generalmente, RDB tiene un impacto mínimo en la latencia de escritura durante la operación de guardado porque el trabajo se descarga. El costo principal de rendimiento es el pico de CPU y la ráfaga inicial de E/S requerida cuando ocurre el fork y durante la escritura del archivo grande.
Tiempo de Recuperación: RDB se carga muy rápidamente al reiniciar porque es un único archivo optimizado, minimizando la latencia de recuperación.
Compensación de Durabilidad: Si Redis falla entre guardados programados (por ejemplo, cada 5 minutos), todas las escrituras realizadas desde el último guardado se pierden. Esto hace que RDB sea menos duradero que AOF.

Configuración de Guardados RDB

Los guardados RDB se configuran usando la directiva save en el archivo redis.conf, especificando intervalos de tiempo y el número de cambios:

save 900 1     # Guardar si 1 clave cambió en 900 segundos (15 minutos)
save 300 10    # Guardar si 10 claves cambiaron en 300 segundos (5 minutos)
save 60 10000  # Guardar si 10000 claves cambiaron en 60 segundos (1 minuto)

2. Persistencia del Archivo de Solo Anexión (AOF)

AOF registra cada operación de escritura recibida por el servidor Redis en un archivo de registro de solo anexión. Cuando Redis se reinicia, reproduce estos comandos secuencialmente para reconstruir el conjunto de datos.

Cómo Funciona AOF y su Impacto en el Rendimiento

A diferencia de RDB, AOF se centra en el registro transaccional. El perfil de rendimiento depende en gran medida de la política de fsync, que dicta con qué frecuencia Redis obliga al sistema operativo a escribir los datos almacenados en búfer en el disco físico.

Políticas de Fsync de AOF:

Política	Configuración `appendfsync`	Durabilidad	Impacto en el Rendimiento
Cada Segundo	`everysec`	Buena en operación normal; un fallo puede perder aproximadamente un segundo de escrituras confirmadas	Buen equilibrio; elección común en producción.
Sin Sincronización	`no`	Pobre (depende del búfer del SO)	Más rápido; máximo riesgo de pérdida de datos ante un fallo del SO.
Siempre	`always`	Política de durabilidad AOF más fuerte	Más lento; aumento significativo de latencia debido a la sincronización de disco en cada escritura.

Consideraciones de Rendimiento:

Latencia de Escritura: Al usar appendfsync always, cada comando de escritura incurre en la latencia de una sincronización de disco, ralentizando significativamente las operaciones en comparación con RDB o las operaciones en memoria. Usar everysec mitiga esto significativamente al agrupar los fsyncs.
Tiempo de Recuperación: Los archivos AOF pueden volverse grandes y reproducir millones de comandos puede llevar más tiempo que cargar un archivo RDB compacto, lo que genera una mayor latencia de recuperación.
Tamaño del Archivo: Los archivos AOF suelen ser mucho más grandes que los archivos RDB porque almacenan comandos (por ejemplo, SET clave valor) en lugar del estado final de la estructura de datos.

Habilitación y Configuración de AOF

AOF está deshabilitado por defecto y se habilita configurando appendonly yes en redis.conf. La configuración crucial es appendfsync:

appendonly yes
appendfilename "appendonly.aof"
# Configuración recomendada para el equilibrio entre durabilidad y velocidad
appendfsync everysec

Análisis de Compensaciones de Rendimiento: AOF vs. RDB

Elegir entre RDB y AOF requiere priorizar ya sea la velocidad operativa bruta (latencia) o la recuperación de datos garantizada.

Latencia y Rendimiento

RDB (Mejor para Velocidad Bruta): Dado que las escrituras son manejadas por un proceso en segundo plano, el hilo principal de Redis ve un impacto mínimo de E/S directa durante los guardados. Esto generalmente resulta en una latencia de escritura general más baja a menos que el sistema esté muy cargado cuando ocurre el fork de BGSAVE.
AOF (modo always): Esta configuración es la más lenta porque la latencia del disco se introduce directamente en cada comando de escritura del cliente, lo que lleva a latencias p99 más altas.
AOF (modo everysec): Proporciona un rendimiento casi similar a RDB para la mayoría de las operaciones, ya que las operaciones fsync se almacenan en búfer y son menos frecuentes.

Durabilidad y Riesgo de Pérdida de Datos

AOF (Mejor para Durabilidad): Proporciona la mayor durabilidad, especialmente con appendfsync always. Incluso con everysec, la pérdida de datos se limita a un segundo.
RDB (Peor para Durabilidad): La pérdida de datos puede abarcar minutos u horas, dependiendo de la programación de guardados.

Tiempo de Recuperación

RDB (Recuperación Rápida): Tiempos de reinicio más rápidos debido al formato binario compacto y optimizado.
AOF (Recuperación Más Lenta): Reproducir un registro de comandos grande puede llevar más tiempo que cargar una instantánea, aumentando el tiempo de inactividad durante los reinicios.

Mejor Práctica: Usar Ambos Métodos de Persistencia

Para entornos que exigen tanto alto rendimiento como fuertes garantías de durabilidad, el enfoque recomendado es habilitar tanto la persistencia RDB como AOF simultáneamente.

Cuando ambos están habilitados, Redis usa el archivo AOF para la reproducción durante el inicio para lograr la máxima consistencia de datos. Continúa generando instantáneas RDB periódicamente.

¿Por qué usar ambos?

Mejores Opciones de Recuperación: Redis normalmente carga AOF primero cuando ambos están habilitados porque generalmente es más completo. Mantener RDB te da un artefacto de respaldo adicional para copias de seguridad y recuperación ante desastres.
Flexibilidad Operativa: RDB es compacto y fácil de archivar, mientras que AOF reduce la ventana de pérdida de datos. Juntos cubren diferentes modos de fallo.

Fragmento de Configuración para Ambos:

# 1. Habilitar RDB
save 900 1

# 2. Habilitar AOF con sincronización 'everysec'
appendonly yes
appendfsync everysec

Gestión del Tamaño del Archivo AOF (Reescritura)

Una preocupación operativa significativa con AOF es el crecimiento del tamaño del archivo. Con el tiempo, el archivo AOF puede volverse masivo ya que registra cada modificación, incluso aquellas que sobrescriben valores anteriores. Para combatir esto, Redis ofrece la reescritura de AOF.

Reescritura de AOF genera un nuevo archivo AOF optimizado que contiene solo el conjunto mínimo de comandos necesarios para reconstruir el estado actual del conjunto de datos. Este proceso se activa automáticamente cuando el tamaño del archivo AOF actual crece más allá de un cierto múltiplo del tamaño base.

auto-aof-rewrite-percentage 100  # Reescribir cuando el archivo AOF sea 100% más grande que el tamaño base
auto-aof-rewrite-min-size 64mb    # No reescribir a menos que el archivo tenga al menos 64 MB

Advertencia sobre la Reescritura: Al igual que el guardado RDB, la reescritura de AOF implica bifurcar el proceso. Si tu sistema tiene limitaciones de memoria, esta duplicación temporal del uso de memoria (la instancia en vivo más la copia que se está reescribiendo) puede provocar inestabilidad o intercambio.

Conclusión

Usa RDB cuando el reinicio rápido, las copias de seguridad compactas y la baja sobrecarga de escritura importen más que perder escrituras recientes. Usa AOF con appendfsync everysec cuando necesites una ventana de recuperación más ajustada sin sincronizar cada escritura. Para muchos sistemas de producción, habilitar ambos te brinda una combinación práctica de durabilidad, conveniencia de copia de seguridad y opciones de recuperación.