Persistenza dei dati

Redis ha fama di essere particolarmente efficiente, e ciò è dovuto in buona parte al suo modo di gestire la persistenza su disco dei dati, permettendo di scegliere tra due diversi meccanismi ma offrendo al contempo l'opportunità di salvare database totalmente in memoria o di funzionare esclusivamente come una memoria cache. In questa lezione, esploriamo le configurazioni che portano a questi diversi comportamenti.

Meccanismi di persistenza: RDB e AOF

Redis dispone di due strategie per la persistenza, entrambe attivabili variando la configurazione:

• RDB, strategia di default, si basa sul salvataggio periodico di uno snapshot dell'intero database;
• AOF mantiene un file di log continuo sul quale verranno annotate tutte le operazioni svolte sul database.

La strategia RDB viene impostata nella configurazione mediante la parola chiave save. Le impostazioni di default sono queste:

save 900 1
save 300 10
save 60 10000

Ciò significa che lo snapshot verrà eseguito in tre circostanze diverse: ogni 900 secondi (15 minuti) purchè sia stata modificata almeno una chiave; ogni 300 secondi (5 minuti) se sono state modificate almeno dieci chiavi; ogni 60 secondi se il numero di chiavi modificate è di almeno diecimila.

All'interno della cartella del server si potrà osservare la presenza di un file denominato dump.rdb che costituisce il salvataggio dell'intero database (dump).

La strategia AOF viene configurata mediante due parole chiave:

• appendonly, che se impostato a yes attiva AOF;
• appendfilename che specifica il nome del file in cui verranno salvati i log.

Cosa scegliere tra AOF e RDB?

Entrambi i meccanismi sono efficaci ma offrono vantaggi e svantaggi:

• RDB:
  • vantaggi: RDB produce come risultato un file compatto, pertanto più agevole da salvare su altri supporti o servizi di storage in Cloud (possibilmente previa cifratura). Inoltre, il recupero dei dati per Redis risulta più efficiente rispetto ad AOF;
  • svantaggi: considerando che il salvataggio dei dati viene eseguito su file ad intervalli di tempo e non con continuità, il rischio più evidente è che un crash del sistema tra uno snapshot e l'altro causi la perdita dei dati;
• AOF:
  • vantaggi: AOF si basa su un log scritto continuamente, pertanto non rischia - a differenza di RDB - di incorrere in perdite di dati in caso di crash. Inoltre, il formato dei file da questo prodotti permette un più facile recupero dei dati in caso di corruzione;
  • svantaggi: i file AOF risultano meno compatti e più voluminosi rispetto a quelli in formato RDB e da ciò consegue un recupero dei dati meno rapido.

Quindi, in linea di massima, conviene utilizzare RDB quando si richiede un salvataggio meno oneroso per il server e si ha particolare interesse ad avere un backup più comodo. AOF va preferito nel caso in cui la principale preoccupazione sia quella di non incorrere mai in perdite di dati. È altresì possibile usare contemporaneamente AOF ed RDB. In tal caso, al recupero dei dati da parte di Redis, verrà preferito il file AOF, la cui completezza è maggiormente garantita.

Database in memory

Redis può rinunciare ad entrambi i meccanismi di persistenza per dare vita a database in memory. Per ottenere ciò, è sufficiente includere nella configurazione le seguenti direttive:

save ""
...
...
appendonly no

di cui la prima eviterà l'azione di RDB, eliminandone gli snapshot temporizzati, e la seconda inibirà AOF. Un database in memory risulta più efficiente di uno che salva dati in memoria e può essere utilizzato per immagazzinare dati ad uso temporaneo la cui perdita non risulterebbe irreparabile per il sistema. Immaginiamo, ad esempio, un database destinato a conservare token di accesso per i client che vogliono interagire con un servizio web. Tali dati sono caratterizzati da una scadenza al termine della
quale vengono cancellati obbligando l'applicazione a richiederne un nuovo rilascio. Sono dati temporanei la cui perdita in caso di crash del sistema non sarebbe grave in quanto il servizio possiede già meccanismi idonei alla loro riproduzione. Un utilizzo del genere trarrebbe inoltre grande vantaggio dalla maggiore efficienza del database, che non dovrebbe occuparsi della persistenza dei dati.

Usare Redis come memoria cache

Redis può anche essere utilizzato come una memoria cache. In tali casi, viene fissata una quantità massima di memoria utilizzabile. Quando questa sarà colma, i dati più vecchi verranno eliminati secondo la politica LRU (Least Recently Used, meno recentemente usato) o LFU (Least Frequently Used, meno frequentemente usato) di più recente introduzione. Per applicare tale configurazione si agisce con due parole chiave:

• maxmemory: specifica il numero di byte che rappresentano la dimensione massima dei dati che possono essere conservati da Redis. Tale impostazione sposa perfettamente il concetto di memoria cache, ma può essere impiegata in tutti gli altri utilizzi del database come soglia di sicurezza per il sistema;
• maxmemory-policy: indica con quale logica, al raggiungimento della soglia impostata con maxmemory, si dovranno scartare dati vecchi per fare spazio a quelli nuovi. I possibili valori sono:
  • noeviction: non avviene alcuno scarto ma il client riceverà un messaggio di errore ad ogni tentata operazione di scrittura;
  • allkeys-lru: lo scarto avviene tra tutte le chiavi secondo una politica LRU;
  • volatile-lru: vengono scartate le chiavi usate meno di recente ma scelte solo tra quelle "a scadenza";
  • allkeys-lfu: lo scarto avviene tra tutte le chiavi secondo una politica LFU;
  • volatile-lfu: vengono scartate le chiavi usate meno frequentemente ma scelte solo tra quelle "a scadenza";
  • allkeys-random: rimozione casuale tra tutte le chiavi;
  • volatile-random: rimozione casuale tra le sole chiavi "a scadenza";
  • volatile-ttl: rimozione delle chiavi "a scadenza" con il TTL (Time To Live) più vicino alla fine.

Backup in Redis

Come si è visto, le strategie stesse con cui vengono gestiti i dati in Redis costituiscono una forma di backup, in quanto danno vita a dei file - in formato RDB o AOF - che rappresentano continuamente un dump del database e possono essere crittografati, salvati in altra sede ed utilizzati per un reintegro ad ogni riavvio del server. È importante che una strategia di backup esista in tutti i casi in cui non si voglia correre il rischio di perdere i dati a disposizione.

Esistono alcuni comandi utili in questo ambito che vale la pena ricordare:

• SAVE: esegue un salvataggio sincrono del database;
• BGSAVE: esegue un salvataggio in modalità asincrona. In pratica, il server risponde OK immediatamente, lasciando che il backup avvenga in background;
• BGREWRITEAOF: crea una nuova versione, ottimizzata, del file AOF prodotto sinora. Qualora tale operazione non andasse in porto completamente, il file AOF originale non sarebbe perso ma rimarrebbe comunque accessibile e perfettamente funzionante;
• SHUTDOWN: tale comando interrompe il database ma può rientrare a pieno titolo in questo ambito in quanto l'arresto del servizio è proprio uno dei momenti in cui va applicata la strategia di backup scelta. Il comando SHUTDOWN esegue quattro operazioni: chiude la connessione con ogni client; esegue un salvataggio RDB se è configurata
  la direttiva SAVE; completa il file AOF se tale tipo di persistenza è attiva; arresta il server. In aggiunta a ciò, si può invocare il comando come SHUTDOWN SAVE per arrestare il servizio eseguendo un salvataggio di dati anche se ciò non rientra nella configurazione e SHUTDOWN NOSAVE per forzare l'arresto senza salvataggio di dati.