Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Dal relazionale a Redis

Confronto tra la progettazione più tradizionale utilizzata nel contesto dei database relazionali, e ciò che è più indicato fare con un DBMS NoSQL come Redis
Confronto tra la progettazione più tradizionale utilizzata nel contesto dei database relazionali, e ciò che è più indicato fare con un DBMS NoSQL come Redis
Link copiato negli appunti

Con Redis, è possibile creare qualsiasi tipo di database, al pari di quanto si potrebbe fare con DBMS relazionali. Tabelle,
record, chiavi primarie e qualsiasi altro concetto di tale ambito può essere realizzato in uno o più modi sfruttando funzioni e
strutture dati che Redis ha da offrire.

Flessibilità di Redis

Nel corso di questa guida, abbiamo sottolineato più volte che un database Redis costituisce una grande struttura dati
key/value (pensiamo a una HashMap del mondo Java, a un dizionario di Python piuttosto che a un array associativo di PHP).
Tale struttura può sembrare rigida e limitata a specifici usi ma non è così e ciò grazie alle connotazioni che chiavi e valori
possono assumere.

Le chiavi possono essere segmentate definendo al loro interno un percorso logico attraverso le informazioni.
Se, ad esempio, stessimo lavorando ad un database per una biblioteca e dovessimo rappresentare con una chiave un testo presente nel
catalogo, piuttosto che utilizzare una sequenza alfanumerica poco significativa potremmo usare come chiave una sorta
di percorso logico tipo "catalogo:narrativa:it:23". Ciò, sfruttando i due punti come separatore, descriverebbe la connotazione del testo:
l'oggetto fa parte del catalogo, il suo genere è narrativa, è in lingua italiana ed ha un identificativo equivalente al numero 23. Sarà cura di
chi progetta il database assumere convenzioni idonee affinchè si sappia a priori se il numero finale è relativo all'intero catalogo o ad un ambito più
ristretto e quale sia il reale significato dei segmenti. Chi ha esperienza di progettazione di servizi web potrebbe pensare questa segmentazione
come un qualcosa di simile all'organizzazione dei percorsi in REST.

Altro aspetto da tenere in considerazione: gli oggetti corrispondenti alle chiavi non sono solo semplici stringhe ma strutture dati
(liste, insiemi, hashmap, sorted set) che permettono di dotare l'informazione di un'architettura interna.

La convivenza di questi due aspetti permette di strutturare i dati sia in modalità embedded, innestando in corrispondenza di una
chiave un intero oggetto (rappresentato, ad esempio, con una hashmap) sia instaurando collegamenti tra più oggetti inserendo nel valore di uno
il collegamento alla chiave dell'altro.

Approccio su database relazionali

La modulazione tra i due aspetti prima citati - segmentazione delle chiavi e strutture dati nei valori - offre la possibilità
di scegliere quale approccio seguire per creare in Redis ciò che assomiglia alle classiche tabelle relazionali. Tornando all'esempio della
biblioteca, in un database relazionale, potremmo scegliere come approccio la creazione di una tabella con funzione di catalogo di cui
ogni record, rappresentando un testo, potrebbe avere tra gli altri campi:

  • una chiave primaria, spesso un intero in autoincremento;
  • un riferimento ad un record della tabella "autori";
  • la lingua del testo, espressa - immaginiamo - come codice di due lettere (ad esempio, "it");
  • il genere espresso anche come stringa, pensiamo a "narrativa"

Con una tabella così in un database relazionale potremmo eseguire ricerche in base al genere del testo

SELECT * FROM catalogo WHERE genere='narrativa'

alla sua lingua

SELECT * FROM catalogo WHERE lingua='it'

o per chiave primaria

SELECT * FROM catalogo WHERE id=23

Come si potrebbe ribaltare in Redis tale situazione?

Approccio in Redis

Tutto ciò potrebbe essere reso in Redis usando una chiave tipo "catalogo:genere:lingua:id"
ed inserendo nel valore una struttura dati in cui ogni campo rappresenti un diverso connotato dell'opera:

> HMSET catalogo:politica:en:156 titolo "America and Asia" autore "John Red" pagine 228
OK
> HMSET catalogo:politica:it:71 titolo "Capire l'Europa" autore "Ernesto Verdi" pagine 412
OK
> HMSET catalogo:narrativa:it:34 titolo "Una bella gita" autore "Elisa Marroni" pagine 301

In questo modo, potremmo avere già a disposizione il corrispondente di un record relazionale (la hashmap come valore) e alcuni
tipici filtri che siamo abituati ad operare con la clausola WHERE del SQL sfruttando il comando KEYS e definendo appropriati pattern di
ricerca:

Potremmo eseguire ricerche estraendo tutte le chiavi del catalogo:

> KEYS catalogo*
1) "catalogo:narrativa:it:34"
2) "catalogo:politica:en:156"
3) "catalogo:politica:it:71"

cercando solo testi in italiano:

> KEYS *:it:*
1) "catalogo:narrativa:it:34"
2) "catalogo:politica:it:71"

o tutti quelli di narrativa

> keys *:narrativa:*
1) "catalogo:narrativa:it:34"

Di questo passo, abbiamo creato strutture rapidamente accessibili già predisposte per determinati tipi di ricerca. Come si può immaginare,
sarà sufficiente procedere ad ulteriori adattamenti per predisporre le chiavi per facilitare le ricerche più frequenti. Per il resto
delle elaborazioni potremo ricorrere a quanto disponibile nel linguaggio di programmazione che useremo per interagire con Redis.

A seconda delle necessità o delle preferenze personali, le chiavi definite possono essere raccolte in ulteriori strutture dati creando
qualcosa di molto simile alle tabelle. Quella che segue è una lista che raccoglie alcuni elementi creando pertanto una collezione:

> LPUSH catalogo:selezione_politica catalogo:politica:en:156 catalogo:politica:it:71

Ogni elemento è stato inserito in una lista, in maniera ordinata in quanto queste strutture dati mantengono la posizione di inserimento.
Con la ricchezza di funzioni offerte da Redis, si potrà variare il modo di manipolare gli elementi e di recuperarne il valore.
Altra opzione piuttosto utile per applicazioni simili è il sorted set. Associando uno score ad ogni voce permette attività di ricerca molto
elastiche. Ad esempio, potremmo creare una selezione simile associando come punteggio un timestamp indicante data e ora di registrazione
dell'elemento nella struttura dati:

> ZADD catalogo:selezione_politica 1426156647 catalogo:politica:it:71
(integer) 1
> ZADD catalogo:selezione_politica 1503484647 catalogo:politica:en:156
(integer) 1

Una volta inseriti nel sorted set potrebbero essere letti tutti o in parte con ZRANGE:

> ZRANGE catalogo:selezione_politica 0 -1
1) "catalogo:politica:it:71"
2) "catalogo:politica:en:156"

o filtrati in base al punteggio come nel seguente caso in cui selezioniamo tutti i record registrati tra il 1° gennaio 2016 e il 31 dicembre
2017:

> ZRANGEBYSCORE catalogo:selezione_politica 1451606400 1514764799
1) "catalogo:politica:en:156"

Che si sia scelto una modalità o l'altra di immagazzinare oggetti, avendo a disposizione la chiave se ne potrà estrarre il contenuto con:

> HGETALL catalogo:politica:en:156
1) "titolo"
2) "America and Asia"
3) "autore"
4) "John Red"
5) "pagine"
6) "228"

Ti consigliamo anche