Redis è un database che fa parte del movimento NoSQL e rappresenta uno dei progetti più interessanti di questo nuovo panorama.

Forse non tutti sanno che il progetto è stato lanciato da un noto programmatore italiano, Salvatore ‘antirez’ Sanfilippo, che qualcuno di voi potrebbe già conoscere per altri suoi lavori come HPing o Lloogg. Lo abbiamo contattato affinché ci descrivesse meglio il funzionamento e le caratteristiche di Redis.

Presentati e prova ad illustrare Redis e la sua architettura per il pubblico che ancora non lo conosce.

Redis è un database un pò bizzarro, rispetto ai canoni a cui siamo abituati, per due motivi principali:

1) Tiene tutti i dati in memoria anche se persiste sul disco. In pratica il disco serve solo nel caso in cui il database viene fermato e riavviato, a leggere nuovamente tutto il data set in memoria. Ma tutti gli accessi in lettura e scrittura vengono gestiti principalmente in RAM. Questo permette ad un singolo server Redis che gira su una macchina Linux normalissima, su un solo core, di raggiungere l’interessante prestazione di 100 mila query al secondo. Cosa più interessante le query in lettura e scrittura prendono lo stesso tempo.

2) Le operazioni che supporta sono molto diverse da quelle di un database SQL. Non c’è il concetto di tabella, e non è un semplice database Key-Value a cui si associa ad una stringa (la chiave) un’altra stringa (il valore). Infatti i valori possono essere di altri tipi, come liste, insiemi, insiemi ordinati, o semplicemente stringhe.

L’idea di mantenere tutto il dataset in RAM aiuta a migliorare le prestazioni, ma cosa succede quando la memoria non è sufficiente?

L’idea di mantenere tutto il dataset in RAM aiuta a migliorare le prestazioni, ma cosa succede quando la memoria non è sufficiente?

Nella versione stabile di Redis non c’è modo di andare oltre la RAM. Al massimo Redis può essere configurato per non accettare nuovi dati quando ha utilizzato più di un dato limite di memoria, o di tentare di cancellare le chiavi “volatili” in tal caso per fare spazio alle altre (una chiave volatile è una chiave associata ad un EXPIRE in secondi, poiché Redis supporta l’auto cancellazione delle chiavi dopo tot secondi).

Ma la svolta da questo punto di vista è nella versione non stabile, dentro Git. Si tratta della funzionalità denominata “Virtual Memory”. In pratica Redis implementa un file di swap su cui scarica le chiavi meno usate automaticamente. Se il database supera la dimensione della RAM, tutte le chiavi che sono usate meno spesso vengono trasferite sul disco, per essere ritrasferite indietro in memoria quando saranno nuovamente richieste.

Siccome molte applicazioni sono “sbilanciate” nell’accesso ai dati, ed accedono molto frequentemente ad una piccola percentuale di chiavi, in molti casi le prestazioni di Redis rimangono simili a quelle che esprime quando tutte le chiavi sono in memoria.

La Virtual Memory è già abbastanza stabile e può essere testata. Ho scritto un lungo articolo qui a proposito del suo funzionamento: http://antirez.com/post/redis-virtual-memory-story.html

Tra i piani per il futuro c’è l’opzione di implementare una memoria virtuale. Potresti spiegarci i vantaggi di questo approccio rispetto al lasciar fare tutto al sistema operativo?

Esatto, ho appena parlato di questo. Perché non si può lasciar fare al sistema operativo?

È più semplice di quello che sembra. Il sistema operativo trasferisce o carica dallo swap delle “pagine” di memoria che sono grandi 4096 byte. Redis utilizza delle strutture molti piccole, anche per valori grossi. Ad esempio una lista di Redis, è composta da tanti piccoli Redis Objects. Non solo, il dizionario principale è implementato tramite una hash table, che è una struttura dati ad accesso “molto” casuale. In pratica nella stessa pagina di memoria ci finiscono dati relativi a decine o centinaia di chiavi: se anche una sola chiave è attiva, questa pagina non può essere trasferita su disco.

Per cui la memoria virtuale del sistema operativo funziona malissimo con Redis. C’è un altro motivo importante: in memoria i dati di Redis occupano molto più spazio rispetto a quello occupato dallo stesso dato codificato su disco da Redis. La memoria virtual del sistema operativo non ha idea di cosa ci sia dentro le pagine di memoria, e le trasferisce dal/al disco così come sono. Invece la memoria virtuale di Redis ha più informazioni, e codifica e comprime i valori trasferiti, per cui esegue molto meno input/output sul disco a parità di necessità di swapping.

Come vengono sfruttate la macchine multicpu/multicore e la distribuzione del dataset su più computer?

Attualmente ci sono due modi per sfruttarle: o far girare più istanze di Redis sulla stessa macchina, o usare la Virtual Memory che ha una implementazione basata sui thread, per cui anche se Redis è “single threaded” cioè opera su un singolo thread grazie ad una tecnica chiamata “multiplexing”, la Virtual Memory si avvale di diversi thread (configurabile) in modo da non bloccare gli altri client quando un client ha la necessità di accedere ai dati che sono sul disco.

Redis è un progetto che si discosta dal tradizionale modello relazionale. Su cosa punteresti per invogliare gli utenti a provarlo?

Faccio un esempio banale. Per implementare su MySQL un sistema semplicissimo di commenti dove ogni nuovo commento sta in cima alla pagina (ad esempio nel caso di un blog), su MySQL devo creare una tabella, mettere l’ID del post, e usare ORDER BY anche se tutto ciò che voglio è prendere i commenti nello stesso ordine in cui li ho inseriti o nell’ordine inverso.

Su Redis invece tutto quello che devo fare è, per ogni commento:

LPUSH post:100:comments

LPUSH aggiunge alla testa della lista contenuta nella chiave “post:100:comments” (dove 100 è un esempio di ID del post).

Per prendere i primi 10 commenti in ordine inverso nel quale li ho postati, mi basta scrivere:

LRANGE post:100:comments 0 9

Quale tipo di progetto potrebbe beneficiare maggiormente dall’uso di Redis al posto di un dbms relazionale?

I progetti che hanno grandi traffici, o dove i dati sono sistemati in modo da necessitare operazioni atomiche. Ad esempio Redis supporta intersezioni tra i set, per cui è facile implementare un sistema di tag. Allo stesso modo è facilissimo implementare una “score board” con i sorted set. In pratica si inseriscono in Redis dei valori che hanno un dato punteggio: anche con milioni di dati Redis inserirà questi dati in O(log(N)) ma con tempi costanti davvero bassi.

Questi dati sono inseriti in maniera ordinata, dunque posso chiedere a Redis: quali sono i primi 10 elementi di questo sorted set? (simile a SELECT * FROM
table ORDER BY score LIMIT 0 10), o posso chiedere a Redis di darmi tutti gli elementi in cui lo score è compreso tra due valori. Queste operazioni sono molto veloci, per cui più di una azienda di videogame sta usando Redis per gestire i punteggi degli utenti, ad esempio di giochi online molto trafficati.

Quali sono i siti più importanti che utilizzano Redis nel loro backend?

http://engineyard.com
http://github.com
L’applicazione “Boxcar” per iPhone, molto famosa per le notifiche push

Sono alcuni esempi di grosse applicazioni, ma ci sono centinaia di startup che stanno usando Redis in produzione.

Recentemente Redis è arrivato alla versione 1.2 che introduce la nuova modalità di persistenza “append only file”. Ci puoi descrivere il funzionamento e come possono cambiare le prestazioni?

In pratica normalmente Redis salva i dati su un file, di tanto in tanto (in maniera configurabile, ad esempio salva ogni 60 secondi se sono cambiati almeno 5 dati in memoria). Questo è molto veloce e viene fatto da un processo “figlio” in parallelo, ma se la macchina si spegne perché ad esempio c’è un problema con la corrente elettrica, si rischia di perdere gli ultimi 60 secondi di dati.

Con l’Append Only File invece Redis scrive su disco, in un file sequenziale, tutte le operazioni di scrittura che riceve, istantaneamente. Quando viene fatto ripartire, rilegge tali operazioni di scrittura come se le ricevesse dai client, per ricostruire lo stato dei dati in memoria. Questo log però diventa sempre più lungo, ma Redis sa compattarlo in backrground, senza bloccare le richieste che arrivano dai dati.

Le prestazioni sono molto buone anche con l’Append Only File, ma dipende molto da come è configurato Redis, infatti può chiedere al sistema operativo di fare il “flush” dei dati ogni secondo, di lasciar fare al sistema operativo, o di farla ad ogni singola scrittura. Nell’ultimo caso Redis diventa lento ma estremamente “durabile” (molto più di MySQL ad esempio), ogni operazione viene trasferita sul disco prima possibile. Questo va bene per applicazioni finanziarie magari, ma non è una buona idea.

Quando è configurato per fare il flush ogni secondo (scelta consigliata) è quasi veloce come quando l’append only file è disabilitato.

Sul sito sono presenti progetti per usare redis con più di 10 linguaggi, qual è il loro grado di maturità?

Alcuni sono estremamente maturi: Ruby, Python, Java.

Il client PHP scritto da “nostro” Daniele Alessandri è ottimo (Predis) ma per ora necessità di PHP moderni. Chiaramente le librerie dei linguaggi meno utilizzati sono aggiornate meno frequentemente, ma il protocollo di Redis è davvero molto semplice.

Cosa vedi nel futuro di Redis e più in generale dei key-value DB?

Abbiamo una roadmap importante. Nel futuro vedo il rilascio della 2.0 che aggiunge transazioni atomiche, Virtual Memory, e operazioni bloccanti sulla lista. E poi il progetto Redis-cluster, che tenterà di far diventare Redis un database distribuito.

Credo che i Key Value “semplici” siano utili, ma Redis ha aperto un nuovo fronte. Mi piacerebbe che nuovi database adottassero questa politica di Redis ma con implementazioni su disco. Insomma, manca un Tokyo Cabinet con le operazioni offerte da Redis secondo me.

Il movimento NoSQL è molto giovane… vedremo cosa succederà ma io sono abbastanza convinto che finalmente i programmatori si sono “riappropriati” dei database, e non useranno più una sola soluzione (SQL) per tutti i tipi di problemi.

Una curiosità. Come è nato Redis?

Perché con MySQL non riuscivo a scalare http://lloogg.com :)

Nel corso di questi anni hai realizzato molti progetti, hai già qualche nuova idea per il futuro?

Mi vorrei concentrare su Redis per il futuro. È un progetto che ha bisogno di molto sviluppo. Forse tra 5 anni passerò a qualcos’altro ma per ora il mio focus è li.

Dato il successo di Redis pensi di farlo diventare il tuo lavoro principale?

Si, sto provando a lavorare full time a Redis. Forse tra qualche tempo annuncerò delle interessanti novità ;)

Grazie per averci concesso il tuo tempo e per l’ottimo lavoro svolto con Redis. Un plauso anche per la documentazione chiara ed abbondante con numerosi esempi.

Grazie a voi!

(1 Voti | Media: 5 su 5)

7 commenti