Key-value, document-oriented, column family, a grafo, relazionale. Oggi sembra che ci siano tanti tipi di database quanti sono i tipi di dati. Mentre ciò può rendere più difficile la scelta di un database, rende più facile la scelta di quello giusto, per individuare il quale bisogna però sapere cosa cercare e conoscere a fondo le proprie esigenze.

Uno dei tipi meno conosciuti di database è il database a grafo. Progettato per lavorare con dati altamente interconnessi, un database a grafo potrebbe essere descritto come ancor più “relazionale” di un database relazionale. I database a grafo sono ideali se l’obiettivo è catturare relazioni complesse in vaste reti di informazioni.

Database a grafo e database relazionale

In un tradizionale database relazionale o SQL i dati sono organizzati in tabelle. Ogni tabella registra i dati in un formato specifico con un numero fisso di colonne e ogni colonna con il proprio tipo di dati (ora/data, testo a mano libera). Questo modello funziona meglio quando si ha a che fare principalmente con i dati di qualsiasi tabella e non funziona malaccio nemmeno quando si aggregano dati archiviati su più tabelle. Ma al tempo stesso ci sono evidenti limiti.

Pensate un attimo a un database musicale con album, band, etichette e artisti. Se volete segnalare tutti i musicisti presenti in un album di una band pubblicato su una certa etichetta (e sono già quattro diverse tabelle), dovete descrivere esplicitamente queste relazioni. Con un database relazionale ciò avviene attraverso nuove colonne di dati (per le relazioni uno a uno o uno-a-molti) o nuove tabelle (per le relazioni molti-a-molti).

Questo metodo funziona finché si gestisce un numero limitato di relazioni. Se però avete a che fare con milioni o addirittura miliardi di relazioni (amici di amici di amici, per esempio), iniziano a emergere i problemi. Se insomma le relazioni tra i dati (non i dati stessi) sono la vostra preoccupazione principale, allora un diverso tipo di database come quello a grafo diventa pressoché essenziale.

Funzionalità del database a grafo

Il termine grafo deriva dall’uso della parola in ambito matematico dove viene usato per descrivere un insieme di nodi (o vertici), ciascuno contenente informazioni (proprietà) e con relazioni (o bordi) tra i nodi. Un social network è un buon esempio di un grafo. Le persone nella rete sarebbero i nodi, gli attributi di ogni persona (come nome, età e così via) sarebbero le proprietà e le linee che collegano le persone (con etichette come “amico” o “madre” o ” supervisore “) indicherebbero la loro relazione.

In un database convenzionale le query sulle relazioni possono richiedere molto tempo per essere elaborate. Questo perché le relazioni sono implementate con chiavi esterne e interrogate dall’unione di tabelle. L’esecuzione di questa unione è costosa, specialmente quando dovete selezionare un numero elevato di oggetti o, peggio, quando dovete unire più tabelle per eseguire query indirette (ad esempio “amico di un amico”) in cui i database a grafo eccellono.

I database a grafo funzionano memorizzando le relazioni insieme ai dati. Poiché i nodi correlati sono fisicamente collegati nel database, l’accesso a tali relazioni è immediato quanto l’accesso ai dati stessi. In altre parole, invece di calcolare la relazione come devono fare i database relazionali, i database a grafo leggono semplicemente la relazione dallo storage.

Un database a grafo memorizza non solo le relazioni tra gli oggetti in modo nativo, rendendo le query sulle relazioni rapide e semplici, ma consente anche di includere diversi tipi di oggetti e diversi tipi di relazioni nel grafo. Come altri database NoSQL un database a grafo non ha schema. Pertanto, in termini di prestazioni e flessibilità, questi database si avvicinano più ai database di documenti o KeyValue rispetto a quelli relazionali o basati su tabelle.

Casi d’uso del database a grafo

I database a grafo funzionano meglio quando i dati con cui state lavorando sono altamente connessi e devono essere rappresentati da come si collegano o si riferiscono ad altri dati, in genere tramite relazioni di tipo “molti-a-molti”.

Ancora una volta un social network è un esempio utile per capire meglio. I database a grafo riducono la quantità di lavoro necessario per costruire le visualizzazioni di dati presenti nei social network come i feed di attività, o per determinare se potreste conoscere una determinata persona a seconda della sua vicinanza ad altri amici che avete nella rete.

Un’altra applicazione per i database a grafo è la ricerca di modelli di connessione nei dati del grafo che sarebbe difficile da individuare tramite altre rappresentazioni di dati. I sistemi di rilevamento delle frodi per esempio utilizzano database a grafo per portare alla luce relazioni tra entità che altrimenti sarebbero state difficili da notare.

Allo stesso modo, i database a grafo sono adatti per applicazioni che gestiscono le relazioni o le interdipendenze tra entità. Troverete spesso questi database dietro sistemi di gestione dei contenuti e dei beni, sistemi di gestione delle identità e degli accessi e soluzioni di conformità normativa e gestione del rischio.

graph

Query del database grafico

I database a grafo, come altri database NoSQL, utilizzano in genere la propria metodologia di query personalizzata anziché SQL.

Un linguaggio di query a grafo comunemente usato è Cypher, originariamente sviluppato per il database grafico Neo4j. Dalla fine del 2015 Cypher è stato sviluppato come progetto open source separato e numerosi altri vendor lo hanno adottato come sistema di query per i loro prodotti (ad esempio SAP HANA).

Ecco un esempio di una query di Cypher che restituisce un risultato di ricerca per tutti quelli che sono amici di Scott:

MATCH (a: Person {nome: ‘Scott’}) – [: FRIENDOF] -> (b)
RETURN b

Il simbolo (->) viene utilizzato nelle query di Cypher per rappresentare una relazione diretta nel grafico.

Un altro linguaggio di query a grafo, Gremlin, è stato ideato per il framework di calcolo a grafo Apache TinkerPop. La sintassi di Gremlin è simile a quella utilizzata dalle librerie di accesso al database ORM.

Ecco un esempio di una query “amici di Scott” in Gremlin:

g.V (). ha ( “nome”,”Scott”). out ( ‘friendof’)

Molti database a grafo supportano Gremlin tramite una libreria, integrata o di terze parti.

C’è poi SPARQL, originariamente sviluppato dal W3C per interrogare i dati memorizzati nel formato Resource Description Framework (RDF) per i metadati. In altre parole, SPARQL non è stato concepito per le ricerche nel database a grafo, ma può essere utilizzato per esse. Nel complesso, Cypher e Gremlin sono stati adottati in modo più ampio. Le query di SPARQL hanno alcuni elementi che rimandano a SQL, vale a dire le clausole SELECT e WHERE, ma il resto della sintassi è differente.

I database a grafo più popolari

Poiché i database a grafo hanno casi d’uso relativamente di nicchia, non ce ne sono tanti quanti quelli relazionali. Il lato positivo di ciò è che è più facile identificare quelli migliori.

Neo4j

Neo4j è il più maturo (c’è a ben 11 anni) e il più noto dei database a grafo per uso generale. Non utilizza un back-end SQL ed è stato progettato dall’interno verso l’esterno per supportare grandi strutture a grafo, come nelle query che restituiscono centinaia di migliaia di relazioni. Neo4j è disponibile sia in versione open-source gratuita, sia in versione aziendale a pagamento, con quest’ultima che non ha restrizioni sulla dimensione di un set di dati. Si può anche sperimentare Neo4j online tramite la sua Sandbox, che include alcuni set di dati di esempio con cui esercitarsi.

Microsoft Azure Cosmos DB

Il database cloud Azure Cosmos DB è un progetto ambizioso. Ha lo scopo di emulare più tipi di database come tabelle convenzionali, documenti, column family e grafo, il tutto attraverso un servizio unificato con un insieme coerente di API. Un database a grafo è quindi solo una delle varie modalità in cui può operare Cosmos DB, che utilizza il linguaggio di query di Gremlin e API per le query di tipo grafo, oltre a supportare la console Gremlin creata per Apache TinkerPop.

Un altro grande punto di forza di Cosmos DB è che l’indicizzazione, il ridimensionamento e la geo-replicazione vengono gestiti automaticamente nel cloud di Azure, senza alcuna manipolazione da parte dell’utente. Non è ancora chiaro come l’architettura all-in-one di Microsoft si adatti ai database a grafo nativi in termini di prestazioni, ma Cosmos DB offre sicuramente un’utile combinazione di flessibilità e scalabilità.

JanusGraph

JanusGraph è un fork nato dal progetto TitanDB e ora è sotto il controllo della Linux Foundation. Utilizza uno dei numerosi back-end supportati (Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB) per archiviare i dati del grafo, supporta il linguaggio di query di Gremlin (così come altri elementi dallo stack di Apache TinkerPop) e può anche incorporare la ricerca full-text tramite i progetti Apache Solr, Apache Lucene o Elasticsearch.

IBM, uno dei sostenitori del progetto JanusGraph, offre una versione ospitata di JanusGraph su IBM Cloud chiamata Compose per JanusGraph. Come Azure Cosmos DB, Compose per JanusGraph offre scalabilità automatica e disponibilità elevata, con prezzi basati sull’utilizzo delle risorse.