Confronto tra le prestazioni di persistenza AOF e RDB: compromessi

La persistenza in Redis è un compromesso tra la quantità di dati che puoi permetterti di perdere e il carico di lavoro su disco che il tuo server può sopportare. Tuttavia, quando la persistenza è abilitata—consentendo di salvare i dati su disco per il recupero dopo un riavvio—gli sviluppatori devono scegliere un meccanismo. I due metodi principali di persistenza in Redis sono Snapshotting (RDB) e Append-Only File (AOF). Comprendere le implicazioni sulle prestazioni, le caratteristiche di durabilità e i compromessi di configurazione di ciascuno è fondamentale per ottimizzare Redis in modo da soddisfare requisiti applicativi specifici per velocità e sicurezza dei dati.

Gli snapshot RDB sono compatti e veloci da caricare. AOF registra le scritture più frequentemente e di solito offre migliori punti di recupero, ma costa più I/O su disco.

Comprendere la persistenza di Redis

Redis memorizza l'intero dataset in memoria volatile. I meccanismi di persistenza sono necessari per trasferire questi dati su disco in modo che Redis possa ricaricare il dataset al riavvio, garantendo la disponibilità dei dati in caso di interruzioni del servizio o riavvii. Sia RDB che AOF raggiungono questo obiettivo attraverso approcci fondamentalmente diversi, portando a profili di prestazioni distinti.

1. Snapshotting RDB (Redis Database)

RDB crea uno snapshot compatto e puntuale dell'intero dataset a intervalli specificati. Salva questi dati in un file binario (dump.rdb).

Come funziona RDB e il suo impatto sulle prestazioni

La persistenza RDB si basa pesantemente sul comando BGSAVE (Background Save). Quando viene attivato un salvataggio:

Forking: Redis crea un processo figlio dal processo principale.
Snapshotting: Il processo figlio scrive l'intero dataset nel file RDB su disco.
Thread principale non influenzato (per lo più): Il thread principale di Redis continua a servire le richieste dei client senza essere bloccato durante l'operazione di scrittura, poiché il figlio gestisce l'I/O su disco.

Considerazioni sulle prestazioni:

Latenza di scrittura: Generalmente, RDB ha un impatto minimo sulla latenza di scrittura durante l'operazione di salvataggio perché il lavoro viene delegato. Il costo principale in termini di prestazioni è il picco di CPU e il burst iniziale di I/O richiesti quando avviene il fork e durante la scrittura del file di grandi dimensioni.
Tempo di recupero: RDB si carica molto rapidamente al riavvio perché è un singolo file ottimizzato, riducendo al minimo la latenza di recupero.
Compromesso sulla durabilità: Se Redis si blocca tra salvataggi programmati (ad esempio, ogni 5 minuti), tutte le scritture avvenute dall'ultimo salvataggio vengono perse. Questo rende RDB meno durevole di AOF.

Configurare i salvataggi RDB

I salvataggi RDB sono configurati usando la direttiva save nel file redis.conf, specificando intervalli di tempo e il numero di modifiche:

save 900 1     # Salva se 1 chiave è cambiata in 900 secondi (15 minuti)
save 300 10    # Salva se 10 chiavi sono cambiate in 300 secondi (5 minuti)
save 60 10000  # Salva se 10000 chiavi sono cambiate in 60 secondi (1 minuto)

2. Persistenza Append-Only File (AOF)

AOF registra ogni operazione di scrittura ricevuta dal server Redis in un file di log append-only. Quando Redis si riavvia, riproduce questi comandi in sequenza per ricostruire il dataset.

Come funziona AOF e il suo impatto sulle prestazioni

A differenza di RDB, AOF si concentra sulla registrazione transazionale. Il profilo delle prestazioni dipende fortemente dalla politica fsync, che determina la frequenza con cui Redis forza il sistema operativo a scrivere i dati bufferizzati su disco fisico.

Politiche Fsync di AOF:

Politica	Impostazione `appendfsync`	Durabilità	Impatto sulle prestazioni
Ogni secondo	`everysec`	Buona in condizioni normali; un crash può causare la perdita di circa un secondo di scritture riconosciute	Buon equilibrio; scelta comune in produzione.
Nessuna sincronizzazione	`no`	Scarsa (si basa sul buffer del sistema operativo)	Più veloce; massimo rischio di perdita di dati in caso di crash del sistema operativo.
Sempre	`always`	Politica di durabilità AOF più forte	Più lenta; aumento significativo della latenza a causa della sincronizzazione su disco per ogni scrittura.

Considerazioni sulle prestazioni:

Latenza di scrittura: Quando si utilizza appendfsync always, ogni comando di scrittura subisce la latenza di una sincronizzazione su disco, rallentando significativamente le operazioni rispetto a RDB o alle operazioni in memoria. Usare everysec mitiga notevolmente questo problema raggruppando le fsync.
Tempo di recupero: I file AOF possono diventare grandi e riprodurre milioni di comandi può richiedere più tempo rispetto al caricamento di un file RDB compatto, portando a una maggiore latenza di recupero.
Dimensione del file: I file AOF sono tipicamente molto più grandi dei file RDB perché memorizzano comandi (ad esempio, SET chiave valore) piuttosto che lo stato finale della struttura dati.

Abilitare e configurare AOF

AOF è disabilitato per impostazione predefinita e viene abilitato impostando appendonly yes in redis.conf. L'impostazione cruciale è appendfsync:

appendonly yes
appendfilename "appendonly.aof"
# Impostazione consigliata per il compromesso tra durabilità e velocità
appendfsync everysec

Analisi dei compromessi di prestazioni: AOF vs. RDB

Scegliere tra RDB e AOF richiede di dare priorità alla velocità operativa pura (latenza) o al recupero garantito dei dati.

Latenza e Throughput

RDB (Migliore per velocità pura): Poiché le scritture sono gestite da un processo in background, il thread principale di Redis vede un impatto I/O diretto minimo durante i salvataggi. Ciò si traduce generalmente in una latenza di scrittura complessiva inferiore, a meno che il sistema non sia pesantemente caricato quando si verifica il fork BGSAVE.
AOF (modalità always): Questa configurazione è la più lenta perché la latenza del disco viene introdotta direttamente in ogni comando di scrittura del client, portando a latenze p99 più elevate.
AOF (modalità everysec): Fornisce prestazioni quasi simili a RDB per la maggior parte delle operazioni, poiché le operazioni fsync sono bufferizzate e meno frequenti.

Durabilità e Rischio di Perdita di Dati

AOF (Migliore per durabilità): Fornisce la massima durabilità, specialmente con appendfsync always. Anche con everysec, la perdita di dati è limitata a un secondo.
RDB (Peggiore per durabilità): La perdita di dati può estendersi per minuti o ore, a seconda della pianificazione dei salvataggi.

Tempo di Recupero

RDB (Recupero veloce): Tempi di riavvio più rapidi grazie al formato binario compatto e ottimizzato.
AOF (Recupero più lento): Riprodurre un grande log di comandi può richiedere più tempo rispetto al caricamento di uno snapshot, aumentando i tempi di inattività durante i riavvii.

Buona Pratica: Utilizzare Entrambi i Metodi di Persistenza

Per ambienti che richiedono sia alte prestazioni che forti garanzie di durabilità, l'approccio consigliato è abilitare contemporaneamente sia la persistenza RDB che AOF.

Quando entrambi sono abilitati, Redis utilizza il file AOF per la riproduzione durante l'avvio per ottenere la massima coerenza dei dati. Continua a generare periodicamente snapshot RDB.

Perché usarli entrambi?

Migliori scelte di recupero: Redis normalmente carica prima AOF quando entrambi sono abilitati perché di solito è più completo. Mantenere RDB fornisce un artefatto di fallback aggiuntivo per backup e disaster recovery.
Flessibilità operativa: RDB è compatto e facile da archiviare, mentre AOF restringe la finestra di perdita di dati. Insieme coprono diverse modalità di guasto.

Frammento di configurazione per entrambi:

# 1. Abilita RDB
save 900 1

# 2. Abilita AOF con sincronizzazione 'everysec'
appendonly yes
appendfsync everysec

Gestire la Dimensione del File AOF (Riscrittura)

Una preoccupazione operativa significativa con AOF è la crescita della dimensione del file. Nel tempo, il file AOF può diventare enorme poiché registra ogni modifica, anche quelle che sovrascrivono valori precedenti. Per contrastare questo, Redis offre la riscrittura AOF.

La riscrittura AOF genera un nuovo file AOF ottimizzato che contiene solo l'insieme minimo di comandi necessari per ricostruire lo stato corrente del dataset. Questo processo viene attivato automaticamente quando la dimensione del file AOF corrente supera un certo multiplo della dimensione base.

auto-aof-rewrite-percentage 100  # Riscrivi quando il file AOF è più grande del 100% rispetto alla dimensione base
auto-aof-rewrite-min-size 64mb    # Non riscrivere a meno che il file non sia almeno di 64MB

Avvertenza sulla riscrittura: Come il salvataggio RDB, la riscrittura AOF comporta il fork del processo. Se il tuo sistema ha memoria limitata, questo raddoppio temporaneo dell'utilizzo della memoria (l'istanza live più la copia in fase di riscrittura) può portare a instabilità o swapping.

Conclusione

Usa RDB quando il riavvio veloce, i backup compatti e il basso overhead di scrittura sono più importanti della perdita di scritture recenti. Usa AOF con appendfsync everysec quando hai bisogno di una finestra di recupero più stretta senza sincronizzare ogni scrittura. Per molti sistemi di produzione, abilitare entrambi fornisce un mix pratico di durabilità, comodità di backup e opzioni di recupero.