I database della famiglia Key Value sono ispirati a quella struttura dati che, solitamente, in informatica prende il nome di mappa o dizionario: esempi comuni possono essere le HashMap del linguaggio Java o gli array associativi in PHP. In pratica, questi database non possiedono strutture "classiche" come le tabelle, ma tutto ciò che vi viene archiviato dovrà essere fornito sotto forma di coppia chiave/valore: il valore è l'informazione vera e propria, la chiave è ciò che ne consente il recupero in fase di ricerca. Un database key/value può essere considerato come un'unica grande mappa (o dizionario). Illustreremo alcuni principi che saranno utili in fase di progettazione e ne esemplificheremo l'impiego mediante il DBMS Key/Value più diffuso: Redis.
Cosa fare con un database Key/Value
I database di questo tipo sono stati spesso criticati perchè troppo di nicchia, usati ad esempio per svolgere operazioni di cache in cui i dati erano salvati associandoli ad una chiave per il loro ripetuto impiego, senza doverli recuperare nuovamente alla fonte. In effetti, un utilizzo simile è piuttosto adeguato per sistemi di questo tipo, tanto che vengono spesso chiamati in causa per rappresentare cache o immagazzinamento di dati di sessione: tutto ciò è inoltre incoraggiato dalle alte prestazioni offerte da DBMS come Redis.
Eppure, database di questo genere si prestano a moltissimi ulteriori scenari applicativi. Tanto per stabilire un parallelo con il mondo relazionale, ogni record in una tabella dovrebbe essere reso univoco dalla definizione di una chiave primaria costituita da uno o più campi. Quindi, se ci pensiamo bene, ogni tabella di un database relazionale vive di una struttura Key/Value dove la "key" è costituita dalla chiave primaria, mentre il "value" è rappresentato dagli altri campi della stessa riga. Sotto questo aspetto, Redis e simili non sono poi così diversi dalle classiche tabelle relazionali.
Chiavi e valori
Altra critica che è stata mossa a questo tipo di database è che molti di essi trattano per lo più stringhe. In sè, ciò non rappresenterebbe un limite, visto che possiamo sempre convertire qualsiasi oggetto (eventualmente binario) in una sequenza alfanumerica. La mancanza consisterebbe semmai nella possibilità di strutturare in maniera articolata dei valori, in quanto la stringa è per lo più un formato lineare, a meno di compiere delle serializzazioni. Redis ha posto rimedio anche a questo, offrendo la possibilità di inserire strutture dati in un valore. La documentazione ufficiale specifica, infatti, che si tratta non di un sistema di memorizzazione
key/value "piano", bensì di un server di strutture dati. Oltre alle stringhe, i valori potranno essere strutturati in vari modi; avremo infatti:
- liste, ossia sequenze di elementi memorizzati in base alla posizione di inserimento;
- insiemi, anch'esse sequenze di elementi ma che non ammettono duplicati (ne esiste anche la versione ordinata, sorted);
- hashmap, strutture di tipo chiave/valore dove possono essere specificate delle proprietà cui asegnare un valore.
Una descrizione più completa è disponibile sulla documentazione.
Si consideri, inoltre, che le stringhe contenute in queste liste o mappe potrebbero a loro volta essere altre chiavi per poter effettuare un ulteriore recupero: questo implemetenrebbe un meccanismo atto a stabilire relazioni.
In un database key/value, la chiave è l'elemento centrale della memorizzazione: una scelta corretta delle chiavi sia come simbologia che come formato può essere la carta vincente nella progettazione di un database. Le chiavi in Redis sono binary safe, e pertanto potranno essere delle comuni sequenze alfanumeriche o il contenuto di un file non testuale, sebbene chiavi di dimensioni eccessive rischiano di penalizzare le prestazioni in fase di ricerca. È comunque consigliabile definire chiavi "leggibili", che abbiano un formato significativo. Buona norma prevedere di anteporre un prefisso seguito da un separatore (tipicamente per questo si usano i due punti ':').
Poniamo il caso di voler modellare il sistema informativo di una biblioteca. In questo caso, potremo inserire i dati di un utente usando come chiave il suo numero di tessera, e quelli di un libro mediante il numero di inventario: applicheremo a questi appositi prefissi che determineranno l'ambito di utilizzo, producendo ad esempio le chiavi users:12346 e books:567890. Entrambe le chiavi faranno parte della stessa struttura dati - che costituisce il database - ma il loro prefisso li classificherà su due domini diversi.
I prefissi potranno essere più articolati: una chiave tipo posts:845:comments potrebbe consentire di recuperare i commenti relativi al post con id 845. Una tale formattazione delle chiavi svolge, in pratica, il ruolo di separazione tra entità perseguito dalle tabelle nello scenario relazionale.
Esemplificando quanto detto sinora su chiavi e valori, pensiamo ad un record della tabella Users, definita in un database relazionale, così strutturato:
La chiave sarà rappresentata dall'id, mentre tutti gli altri campi possono essere visti come una sequenza di accoppiamenti tra nome del campo e valore inserito. In Redis, potremo rappresentare gli stessi dati in questa maniera:
Potremo usare quindi le hashmap per rappresentare la struttura dei record, più o meno nel modo in cui JSON fa in altri ambiti NoSQL.
Enunciate quali sono le linee guida con cui sceglieremo il formato delle chiavi e la struttura dei valori, possiamo pensare ad un esempio più pratico che realizzeremo nella prossima lezione.
