Perché gli sviluppatori dovrebbero utilizzare database a grafo

Venti anni fa, il mio team di sviluppo ha creato un motore di elaborazione del linguaggio naturale che ha scansionato annunci di lavoro, auto e immobili per categorie ricercabili. Sapevo che avevamo una difficile sfida per la gestione dei dati. I dati in alcuni tipi di annunci erano relativamente semplici, come l'identificazione di marche e modelli di automobili, ma altri richiedevano più inferenze, come l'identificazione di una categoria di lavoro in base a un elenco di competenze.

Abbiamo sviluppato un modello di metadati che catturava tutti i termini ricercabili, ma il motore di elaborazione del linguaggio naturale richiedeva al modello di esporre relazioni significative di metadati. Sapevamo che la progettazione di un modello di metadati con connessioni arbitrarie tra punti dati in un database relazionale era complessa, quindi abbiamo esplorato l'utilizzo di database a oggetti per gestire il modello.

Quello che stavamo cercando di realizzare allora con i database a oggetti può essere fatto meglio oggi con i database a grafo. I database di grafici memorizzano le informazioni come nodi e dati specificando le loro relazioni con altri nodi. Sono architetture collaudate per l'archiviazione di dati con relazioni complesse.

L'utilizzo del database grafico è sicuramente cresciuto negli ultimi dieci anni, poiché le aziende hanno preso in considerazione altre tecnologie NoSQL e big data. Il mercato globale dei database grafici è stato stimato a $ 651 milioni nel 2018 e si prevede che crescerà fino a $ 3,73 miliardi entro il 2026. Ma molte altre tecnologie di gestione dei big data, tra cui Hadoop, Spark e altre, hanno visto una crescita molto più significativa in termini di popolarità, adozione di competenze, e casi d'uso di produzione rispetto ai database a grafo. In confronto, la dimensione del mercato della tecnologia per big data è stata stimata a $ 36,8 miliardi nel 2018 e si prevede che crescerà fino a $ 104,3 miliardi entro il 2026.

Volevo capire perché più organizzazioni non considerano i database a grafo. Gli sviluppatori pensano agli oggetti e utilizzano regolarmente rappresentazioni gerarchiche dei dati in XML e JSON. I tecnologi e gli stakeholder aziendali comprendono intrinsecamente i grafici poiché Internet è un grafico interconnesso tramite collegamenti ipertestuali e concetti come amici e amici di amici dai social network. Allora perché più team di sviluppo non hanno utilizzato database a grafo nelle loro applicazioni?

Apprendimento dei linguaggi di query dei database a grafo

Sebbene possa essere relativamente facile comprendere la modellazione dei nodi e delle relazioni utilizzate nei database a grafo, interrogarli richiede l'apprendimento di nuove pratiche e abilità.

Diamo un'occhiata a quell'esempio di calcolo di un elenco di amici e amici di amici. Quindici anni fa, ho co-fondato un social network di viaggi e ho deciso di mantenere semplice il modello di dati archiviando tutto in MySQL. La tabella che memorizzava un elenco di utenti aveva un auto join per rappresentare gli amici ed era una query relativamente semplice per estrarre l'elenco di un amico. Ma raggiungere l'elenco di un amico di un amico richiedeva una query mostruosamente complessa che funzionava ma non funzionava bene quando gli utenti avevano reti estese.

Ho parlato con Jim Webber, capo scienziato di Neo4j, uno dei database di grafi consolidati disponibili, su come costruire una query di amici di amici. Gli sviluppatori possono interrogare i database a grafo Neo4j utilizzando RDF (Resource Description Framework) e Gremlin, ma Webber mi ha detto che oltre il 90% dei clienti utilizza Cypher. Ecco come appare la query in Cypher per l'estrazione di amici e amici di amici:

MATCH (me:Person {name:'Rosa'})-[:FRIEND*1..2]->(f:Person)

WHERE me f

RETURN f

Ecco come capire questa query:

  • Trovami il modello in cui è presente un nodo con l'etichetta Persona e un nome di proprietà: "Rosa" e collegalo alla variabile "io". La query specifica che "io" ha una relazione AMICO in uscita in profondità 1 o 2 con qualsiasi altro nodo con un'etichetta Persona e lega tali corrispondenze alla variabile "f".
  • Assicurati che "io" non sia uguale a "f", perché sono un amico dei miei amici!
  • Restituisci tutti gli amici e gli amici degli amici

La query è elegante ed efficiente ma ha una curva di apprendimento per chi è abituato a scrivere query SQL. Qui sta la prima sfida per le organizzazioni che si spostano verso i database a grafo: SQL è un insieme di competenze pervasivo e Cypher e altri linguaggi di query a grafo sono una nuova abilità da imparare.

Progettazione di gerarchie flessibili con database a grafo

Cataloghi di prodotti, sistemi di gestione dei contenuti, applicazioni di gestione dei progetti, ERP e CRM utilizzano tutti gerarchie per classificare e contrassegnare le informazioni. Il problema, ovviamente, è che alcune informazioni non sono veramente gerarchiche e gli argomenti devono creare un approccio coerente per strutturare l'architettura dell'informazione. Questo può essere un processo doloroso, soprattutto se c'è un dibattito interno sulla strutturazione delle informazioni o quando gli utenti finali dell'applicazione non riescono a trovare le informazioni che cercano perché si trovano in una parte diversa della gerarchia.

Non solo i database a grafo abilitano gerarchie arbitrarie, ma consentono anche agli sviluppatori di creare diverse visualizzazioni della gerarchia per esigenze diverse. Ad esempio, questo articolo sui database a grafo potrebbe essere visualizzato in gerarchie in un sistema di gestione dei contenuti per la gestione dei dati, tecnologie emergenti, settori che probabilmente utilizzeranno database a grafo, casi d'uso comuni di database a grafo o per ruoli tecnologici. Un motore di raccomandazione ha quindi una serie di dati molto più ricca per abbinare i contenuti all'interesse degli utenti.

Ho parlato con Mark Klusza, co-fondatore di Construxiv, una società che vende tecnologie al settore edile, tra cui Grit, una piattaforma di pianificazione delle costruzioni. Se guardi il programma di un progetto di costruzione commerciale, vedrai riferimenti a più mestieri, attrezzature, parti e riferimenti di modello. Un singolo pacchetto di lavoro può facilmente contenere centinaia di attività con dipendenze nel piano del progetto. Questi piani devono integrare i dati di ERP, Building Information Modeling e altri piani di progetto e presentare le viste a programmatori, project manager e subappaltatori. Klusza ha spiegato: “Utilizzando un database a grafo in Grit, creiamo relazioni molto più ricche su chi sta facendo cosa, quando, dove, con quale attrezzatura e con quali materiali. Ciò ci consente di personalizzare le visualizzazioni e di prevedere meglio i conflitti di pianificazione del lavoro ".

Per sfruttare le gerarchie flessibili, aiuta a progettare le applicazioni da zero con un database a grafo. L'intera applicazione viene quindi progettata in base all'interrogazione del grafico e allo sfruttamento dei nodi, delle relazioni, delle etichette e delle proprietà del grafico.

Le opzioni di implementazione del cloud riducono le complessità operative

La distribuzione di soluzioni di gestione dei dati in un data center non è banale. L'infrastruttura e le operazioni devono considerare i requisiti di sicurezza; esaminare le considerazioni sulle prestazioni per dimensionare server, storage e reti; e anche rendere operativi i sistemi replicati per il ripristino di emergenza.

Le organizzazioni che sperimentano i database a grafo ora hanno diverse opzioni cloud. Gli ingegneri possono distribuire Neo4j su GCP, AWS, Azure o sfruttare Aura di Neo4j, un database come servizio. TigerGraph ha un'offerta cloud e kit di avvio per casi d'uso come 360 ​​clienti, rilevamento delle frodi, motori di raccomandazione, analisi dei social network e analisi della catena di fornitura. Inoltre, i fornitori di cloud pubblico dispongono di funzionalità di database a grafo, tra cui AWS Neptune, Gremlin API in CosmoDB di Azure, JanusGraph open source su GCP o le funzionalità di grafo nei servizi di database cloud di Oracle.

Torno alla mia domanda iniziale. Con tutti i casi d'uso interessanti, piattaforme di database a grafo mature disponibili, opportunità per imparare lo sviluppo di database a grafo e opzioni di distribuzione cloud, perché più organizzazioni tecnologiche non utilizzano database a grafo?