Cos'è un database a grafo? Un modo migliore per archiviare i dati connessi

Valore-chiave, orientato al documento, famiglia di colonne, grafico, relazionale ... Oggi ci sembra di avere tanti tipi di database quanti sono i tipi di dati. Sebbene ciò possa rendere più difficile la scelta di un database, semplifica la scelta del  database giusto . Naturalmente, ciò richiede di fare i compiti. Devi conoscere i tuoi database. 

Uno dei tipi di database meno conosciuti è il database a grafo. Progettato per lavorare con dati altamente interconnessi, un database a grafo potrebbe essere descritto come più "relazionale" di un database relazionale. I database grafici brillano quando l'obiettivo è catturare relazioni complesse in vaste reti di informazioni. 

Ecco uno sguardo più da vicino a cosa sono i database a grafo, perché sono diversi da altri database e quali tipi di problemi di dati sono stati creati per risolvere.

Database a grafo vs. database relazionale

In un database relazionale o SQL tradizionale, i dati sono organizzati in tabelle. Ogni tabella registra i dati in un formato specifico con un numero fisso di colonne, ogni colonna con il proprio tipo di dati (numero intero, ora / data, testo in formato libero, ecc.).

Questo modello funziona meglio quando hai a che fare principalmente con i dati di una qualsiasi tabella. Inoltre, non funziona troppo male quando si aggregano i dati archiviati su più tabelle. Ma quel comportamento ha alcuni limiti notevoli.

Considera un database musicale, con album, band, etichette e artisti. Se vuoi segnalare tutti gli artisti che sono stati presenti in questo album da quella band rilasciata su queste etichette - quattro diverse tabelle - devi descrivere esplicitamente quelle relazioni. Con un database relazionale, puoi farlo tramite nuove colonne di dati (per relazioni uno-a-uno o uno-a-molti) o nuove tabelle (per relazioni molti-a-molti).

Questo è pratico fintanto che gestisci un numero modesto di relazioni. Se hai a che fare con milioni o addirittura miliardi di relazioni, ad esempio amici di amici di amici, queste domande non si adattano bene.

In breve, se le  relazioni tra i dati , non i dati stessi, sono la tua preoccupazione principale, allora è necessario un diverso tipo di database, un database a grafo.

Caratteristiche del database grafico

Il termine "grafico" deriva dall'uso della parola in matematica. Viene utilizzato per descrivere una raccolta di nodi (o vertici ), ciascuno contenente informazioni ( proprietà ) e con relazioni (o bordi ) etichettati tra i nodi.

Un social network è un buon esempio di grafico. Le persone nella rete sarebbero i nodi, gli attributi di ogni persona (come nome, età e così via) sarebbero proprietà e le linee che collegano le persone (con etichette come "amico" o "madre" o " supervisore ") indicherebbe la loro relazione. 

In un database convenzionale, l'elaborazione delle query sulle relazioni può richiedere molto tempo. Questo perché le relazioni vengono implementate con chiavi esterne e interrogate unendo tabelle. Come qualsiasi DBA SQL può dirti, eseguire join è costoso, soprattutto quando devi ordinare un gran numero di oggetti o, peggio, quando devi unire più tabelle per eseguire il tipo di query indirette (ad esempio "amico di un amico") in cui eccellono i database a grafo. 

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 come 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 dalla memoria. La soddisfazione delle query è una semplice questione di camminare o "attraversare" il grafico.  

Un database a grafo non solo memorizza le relazioni tra gli oggetti in modo nativo, rendendo rapide e facili le query sulle relazioni, ma consente di includere diversi tipi di oggetti e diversi tipi di relazioni nel grafico. Come altri database NoSQL, un database a grafo è privo di schema. Pertanto, in termini di prestazioni e flessibilità, i database a grafo sono più vicini ai database dei documenti o agli archivi di valori-chiave di quanto non facciano i database relazionali o orientati alle tabelle.

Casi d'uso del database di grafici

I database a grafo funzionano meglio quando i dati con cui stai lavorando sono altamente connessi e dovrebbero essere rappresentati dal modo in cui si collegano o si riferiscono ad altri dati , in genere tramite relazioni molti-a-molti.

Ancora una volta, un social network è un utile esempio. I database di grafici riducono la quantità di lavoro necessaria per costruire e visualizzare le visualizzazioni dei dati trovate nei social network, come i feed delle attività, o per determinare se potresti conoscere o meno una determinata persona a causa della sua vicinanza ad altri amici che hai nella rete.

Un'altra applicazione per i database a grafo è la ricerca di schemi di connessione nei dati del grafico che sarebbero difficili da estrarre tramite altre rappresentazioni di dati. I sistemi di rilevamento delle frodi 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 una scelta naturale per le applicazioni che gestiscono le relazioni o le interdipendenze tra le entità. Troverai spesso database a grafo dietro motori di raccomandazione, sistemi di gestione di contenuti e risorse, sistemi di gestione di identità e accessi e soluzioni di gestione del rischio e conformità normativa. 

Query di database di grafici

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

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

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

PARTITA (a: Persona {name: 'Scott'}) - [: FRIENDOF] -> (b) RETURN b 

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

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

Di seguito è riportato un esempio di una query "amici di Scott" a Cremlino:

gV (). has ("name", "Scott"). out ("friendof") 

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

Ancora un altro linguaggio di query è SPARQL. È stato originariamente sviluppato dal W3C per eseguire query sui dati archiviati nel formato RDF (Resource Description Framework) per i metadati. In altre parole, SPARQL non è stato concepito per le ricerche nei database a grafo, ma può essere utilizzato per esse. Nel complesso, Cypher e Gremlin sono stati adottati in modo più ampio.

Le query SPARQL hanno alcuni elementi che ricordano SQL, vale a dire  SELECTe WHEREclausole, ma il resto della sintassi è radicalmente dissimile. Non pensare affatto a SPARQL come correlato a SQL, o per quella materia ad altri linguaggi di query di grafi.

Database grafici popolari

Poiché i database a grafo servono un caso d'uso relativamente di nicchia, non ce ne sono tanti quanti sono i database relazionali. Tra i lati positivi, questo rende i prodotti straordinari più facili da identificare e discutere.

Neo4j

Neo4j è facilmente il più maturo (11 anni e oltre) e il più noto dei database a grafo per uso generale. A differenza dei precedenti prodotti di database a grafo, non utilizza un back-end SQL. Neo4j è un database grafico nativo che è stato progettato dall'interno verso l'esterno per supportare grandi strutture di grafi, come nelle query che restituiscono centinaia di migliaia di relazioni e altro ancora.

Neo4j è disponibile in entrambe le edizioni gratuite open source e aziendali a pagamento, con quest'ultima senza restrizioni sulla dimensione di un set di dati (tra le altre funzionalità). Puoi anche sperimentare Neo4j online tramite il suo Sandbox, che include alcuni set di dati di esempio con cui esercitarti.

Vedi la recensione di Neo4j per maggiori dettagli.

Microsoft Azure Cosmos DB

Il database cloud di Azure Cosmos DB è un progetto ambizioso. Ha lo scopo di emulare più tipi di database: tabelle convenzionali, orientato ai documenti, famiglie di colonne e grafici, il tutto attraverso un unico servizio unificato con un set coerente di API.

A tal fine, un database a grafo è solo una delle varie modalità in cui può funzionare Cosmos DB. Utilizza il linguaggio di query Gremlin e l'API per query di tipo grafico e supporta la console Gremlin creata per Apache TinkerPop come un'altra interfaccia.

Un altro grande punto di forza di Cosmos DB è che l'indicizzazione, il ridimensionamento e la replica geografica vengono gestiti automaticamente nel cloud di Azure, senza alcuna manipolazione da parte tua. Non è ancora chiaro come l'architettura all-in-one di Microsoft sia all'altezza dei database grafici nativi in ​​termini di prestazioni, ma Cosmos DB offre sicuramente un'utile combinazione di flessibilità e scalabilità.

Per ulteriori dettagli, vedere la recensione di Azure Cosmos DB.

JanusGraph

JanusGraph è stato biforcuto dal progetto TitanDB ed è ora sotto il governo della Linux Foundation. Utilizza uno qualsiasi dei numerosi back-end supportati (Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB) per archiviare i dati del grafico, supporta il linguaggio di query Gremlin (così come altri elementi dallo stack 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.