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

Tipologie di database NoSQL

Un'introduzione al mondo dei database NoSQL, con un panoramica dei principali paradigmi di modellazione dei dati utilizzati in questo ambito.
Un'introduzione al mondo dei database NoSQL, con un panoramica dei principali paradigmi di modellazione dei dati utilizzati in questo ambito.
Link copiato negli appunti

Lo scopo di questa guida è quello di trasferire alcune linee guida generali di progettazione di un database NoSQL, utilizzando come riferimento i paradigmi di strutturazione dei dati più comunemente diffusi in questo ambito. La parola NoSQL, infatti, non indica una ben precisa tipologia di database, bensì è generalmente usata per raggrupare tutti quei DBMS che non possono essere definiti relazionali. Ed infatti, i principali database NoSQL utilizzano paradigmi anche abbastanza differenti l'uno dall'altro, che ovviamente ne condizionano la progettazione, la manutenzione e l'interfacciamento.

Prima di iniziare con le linee guida vere e proprie, quindi, in questa lezione analizzeremo le principali tipologie di database NoSQL attualmente disponibili, in modo da evidenziarne le caratteristiche più distintive nonchè i casi d'uso che ad esse meglio si addicono.

Classificare i DBMS NoSQL

Le categorie che qui analizziamo sono tre, ormai molto diffuse nella pratica comune:

  • database a documenti: in queste soluzioni, la rappresentazione dei dati è affidata a strutture simili ad oggetti, dette documenti, ognuno dei quali possiede un certo numero di proprietà che rappresentano le informazioni. Per i documenti non è obbligatorio avere una struttura rigida, anche se alcuni DBMS permettono di imporne una. Ad esempio, se i documenti devono rappresentare delle persone, probabilmente avremo in tutti delle proprietà piuttosto scontate (nome, cognome, data di nascita), ma potremmo decidere di dotare un documento di un numero di telefono, mentre un altro di una email, in base alle informazioni che possediamo. Questa è una delle principali caratteristiche dei documenti, che non necessitano della definizione di alcuna struttura fissa.
    Volendo fare un parallelo col mondo relazionale, possiamo vedere il documento come l'equivalente del record delle tabelle. I documenti possono essere messi in relazione tra loro con dei riferimenti, e ciò rende questa tipologia di database NoSQL particolarmente adatta a rappresentare delle gerarchie. Osserviamo la figura seguente:

    Figura 1. Strutture a "documenti" (click per ingrandire)

    Strutture a "documenti"

    Tutti i rettangoli in essa presenti costituiscono dei documenti, ognuno dotato di sue proprietà. Immaginiamo che tale database rappresenti la struttura di un'azienda dislocata sul territorio nazionale, in cui vengono registrate infrastrutture e personale: potremmo disporre un documento che rappresenta la sua presenza in una regione italiana connotato da una serie di informazioni che al momento non ci interessano. Ad ogni nodo corrisponderà un elenco di sedi specifiche, ognuna delle quali sarà caratterizzata da ulteriori dettagli e da una lista di documenti, contenenti i dati di ogni dipendente;

  • database key/value: sono costruiti come le strutture dati conosciute in informatica come dizionari o mappe: al loro interno vengono inseriti due valori alla volta, una chiave e il valore ad essa associato. Quest'ultimo contiene l'informazione vera e propria, mentre il primo è l'identificatore che permette l'estrazione rapida del valore dal database. Il loro utilizzo principale è quello di offrire la possibilità di effettuare ricerche rapide di singoli blocchi di informazione. I migliori contesti in cui sono utilizzati questi tipi di database NoSQL sono quelli in cui si trattano valori o collezioni cui è facilmente associabile un identificatore univoco da usare come chiave. Pensiamo, ad esempio, ad un sistema di messaggistica: ogni chiave può rappresentare un "account" cui verranno indirizzate comunicazioni, ed il suo valore corrispondente sarà una lista di messaggi ricevuti. Visto che i database key/store puntano tutto sulla ricerca della velocità, sono spesso ottimizzati per conservare i dati in memoria dinamica e salvarli periodicamente su disco in modo da garantire, sia un certo livello di efficienza delle risposta, sia la persistenza dei dati.
    Tanta rapidità di interazione - oltre alla loro struttura a dizionario - li rende ideali per salvare, ad esempio, dati di sessione in ambiente client/server, dove la chiave rappresente l'ID di sessione, mentre i dati sono memorizzati come valori;
  • database a grafo: funzionano come i grafi, strutture dati che rappresentano una rete di nodi collegati tra loro da archi. Le informazioni possono essere custodite sia nei nodi sia negli archi. La forza di questa tipologia è tutto l'insieme del valore informativo che si può estrapolare ricostruendo percorsi attraverso il grafo. Gestire i grafi non è mai impresa troppo semplice, proprio per la loro struttura intricata, ma il loro contributo è decisivo in casi d'uso in cui si hanno relazioni fortemente correlate tra loro. Pensiamo, ad esempio, ad una rete di trasporti: se ogni nodo rappresenta una città italiana, il collegamento tra due nodi contiene come informazione la distanza chilometrica che tra di esse intercorre. Con un database a grafo si può trovare un percorso tra due città lontane - quindi non collegate direttamente - e, sommando la distanza di ogni tratto, si potrebbe calcolare la distanza totale dalla partenza alla destinazione, più ogni altra grandezza derivata (come tempi, costi, eccetera). Altro caso ormai comunissimo di reti di informazioni sono i
    Social Network. Quando due utenti sono "amici" in un contesto simile, possono essere rappresentati da oggetti messi in relazione tra loro; pertanto si potrebbero proporre nuove potenziali conoscenze ad un utente navigando il grafo e recuperando, per così dire, gli "amici di amici".

    Figura 2. Un esempio di grafo generato dai collegamenti di un account su LinkedIn (click per ingrandire)

    Un esempio di grafo generato dai collegamenti di un account su LinkedIn

Quindi quale database NoSQL utilizzare? Secondo recenti statistiche, MongoDB è il DBMS di questa categoria più utilizzato al mondo, e si basa sull'uso dei documenti come elemento fondamentale di modellazione dei dati. Se, però, i nostri casi d'uso ci suggeriscono di optare per il modello di dati in forma di coppie chiave/valore o a grafo, soprattutto alla ricerca di performance migliori, ci si potrà rivolgere alle altre due categorie di cui sono
splendidi esempi, rispettivamente, Redis e OrientDB.

Nel prosieguo della guida, esploreremo singolarmente le suddette tipologie di database NoSQL, alla ricerca delle caratteristiche che li rendono più adatti a specifici casi d'uso: non mancheranno ovviamente esempi pratici di progettazione di database di ogni tipo.


Ti consigliamo anche