Nel mondo dei database, la gestione e soprattutto l’analisi dei dati complessi e interconnessi è un problema, o meglio un’opportunità, sempre più pressante.
I graph database o database a grafo, sono stati sviluppati per affrontare questo problema, offrendo un modello adatto a rappresentare relazioni complesse tra entità. La mancanza di uno standard unificato per interrogare questi database non ha aiutato la loro adozione.
GQL: un passo avanti significativo nel campo dei database
D’altra parte, l’interesse per i graph database e la graph analytics è molto alta, perché questi permettono di implementare dei casi di uso che altrimenti sarebbero difficili o persino impossibili da realizzare. È qui che entra in scena GQL, Graph Query Language [1], il linguaggio di programmazione standardizzato a livello internazionale, progettato per interrogare e manipolare dati organizzati in strutture a grafo. Questo standard, ufficialmente denominato ISO/IEC 39075:2024, è stato rilasciato ad aprile del 2024 dall’ISO, International Organization for Standardization, l’ente che sviluppa e pubblica standard internazionali.
GQL rappresenta un passo avanti significativo nel campo dei database, così come lo è stato il linguaggio SQL per i database relazionali. Il linguaggio SQL è stato standardizzato proprio da ISO (ISO/IEC 9075) a partire dal lontano 1986. I benefici degli standard, in qualsiasi campo, sono innumerevoli e ciò è evidente anche nel campo dei database. Lo standard SQL da metà degli anni Ottanta in poi ha favorito l’adozione dei database relazionali, rendendo prodotti come Oracle, SQL Server, MySQL onnipresenti in tutte le aziende.
Successivamente, con la crescita di Internet e l’esplosione dei dati, le esigenze di scalabilità e flessibilità delle applicazioni web hanno portato alla ribalta soluzioni alternative ai tradizionali RDBMS.
Database come MongoDB, Cassandra e HBase hanno iniziato a guadagnare popolarità, alimentando il movimento NoSQL, termine con il quale ci si riferisce a quell’insieme di database che utilizzano un modello dati diverso dal modello relazionale.
Approcci per modellare e gestire i dati nei database NoSQL
I database NoSQL offrono diversi approcci per modellare e gestire i dati, come ad esempio:
- Document-oriented: i documenti sono le unità di base di dati e possono contenere campi di tipo diverso. Esempi di database document-oriented sono MongoDB e Couchbase.
- Chiave-valore: i dati sono organizzati in coppie chiave-valore. Esempi di database chiave-valore sono Redis e Riak.
- Wide column store o colonnari: i dati sono organizzati in tabelle, ma i dati vengono archiviati colonna per colonna anziché riga per riga. Esempi di database di questo tipo sono Cassandra e HBase.
- Grafo: i dati sono organizzati in grafi, rappresentando relazioni complesse tra entità. Esempi di database grafo sono Neo4j, Ultipa Graph e Amazon Neptune.
Ad oggi non esiste un linguaggio standard per interrogare o gestire document database, per i database chiave-valore oppure per i database colonnari. Questo era vero anche per i database a grafo, almeno fino ad aprile di quest’anno, prima della pubblicazione del nuovo standard GQL.
GQL: il nuovo standard per interrogare, manipolare e gestire i graph database
Il GQL è un linguaggio di interrogazione, manipolazione e gestione standardizzato per i property graph database, sviluppato grazie al lavoro di una comunità di sviluppatori, esperti e aziende leader nel settore [2]. Questo linguaggio è progettato per essere facile da usare, flessibile e potente, consentendo agli utenti di eseguire query complesse sui dati gestiti in property graph in modo efficiente e scalabile.
I diversi linguaggi per interrogare i graph database
Ad oggi esistono decine di diversi graph database [3]. L’ultimo player a entrare nel mercato dei graph database è un peso massimo, Google. Questa società, ad inizio agosto, ha infatti annunciato la disponibilità del nuovo servizio in cloud, Google Spanner Graph [4].
Il linguaggio Cypher
In generale, ogni vendor ha il proposto il proprio linguaggio di interrogazione, specifico per il proprio graph database. Tra questi, il linguaggio Cypher è sicuramente il più conosciuto. Questo linguaggio è stato introdotto da Neo4J ed è diventato quasi uno standard di fatto. Cypher ha infatti una lunga storia, essendo stato introdotto nel 2011, ben tredici anni prima del GQL. Neo4j ha provato ad aumentarne ulteriormente l’adozione rilasciando le specifiche di Cypher in una versione open source, denominata openCypher. Ad oggi openCypher, è utilizzato e supportato in diversi graph database e in molti tool e applicazioni. Sebbene openCypher sia ampiamente utilizzato e sia un linguaggio open source, era ed è ancora strettamente associato al prodotto dell’azienda che lo ha creato, Neo4j.
Il progetto che ha portato alla definizione di GQL, Graph Query Language
C’è stata una forte spinta del mercato per definire un linguaggio di interrogazione standard de jure e non solo de facto, ufficiale e non strettamente legato ad uno specifico vendor. Nel 2019 l’International Organization for Standardization ha annunciato il progetto che ha portato alla definizione di GQL, Graph Query Language.
Molte aziende hanno nel frattempo continuato a puntare su openCypher. Altre aziende hanno invece deciso di investire su GQL da subito. Ultipa, ad esempio, ha deciso di puntare su questo nuovo standard. Nel 2019 c’era però solo la volontà di creare uno standard e delle linee di principio, basi non sufficienti per definire un linguaggio di interrogazione. L’azienda ha quindi definito nel frattempo il proprio linguaggio di interrogazione e denominato UQL, Ultipa Query Language, ma si è preparata a supportare GQL. Nonostante UQL e GQL abbiano differenze nella sintassi, entrambi i linguaggi si basano su un approccio comune che ha permesso di implementare da subito la maggior parte delle funzionalità obbligatorie di GQL.
Impatto di GQL sul mercato dei graph database
Cypher, openCypher, Gremlin, GSQL, GraphQL, AQL, PGQL, Datalog, FQL, SQL/PGQ, UQL: questo è un elenco, parziale, dei diversi linguaggi di interrogazione creati dai diversi fornitori di graph database. Ogni graph database ha le proprie peculiarità e il proprio linguaggio.
L’introduzione di GQL abiliterà numerosi vantaggi significativi in termini di:
- –Interoperabilità: GQL permetterà una maggiore interoperabilità tra diversi sistemi di database a grafo. Le query definite in GQL potranno essere eseguite su diversi database compatibili.
- Riutilizzo delle competenze: gli sviluppatori potranno applicare le loro conoscenze di GQL su diverse piattaforme. Questo permetterà la riduzione dei costi di formazione per le aziende che utilizzano più sistemi di database a grafo. Per le aziende significherà anche trovare più facilmente le necessarie competenze. Un linguaggio standard renderà infatti più facile per i nuovi utenti approcciarsi ai database a grafo e la curva di apprendimento sarà più dolce, incoraggiando una maggiore adozione di questa tecnologia.
- Mitigazione del vendor lock-in: le aziende saranno meno legate a un singolo fornitore di database a grafo. Sarà più facile migrare da un sistema all’altro, riducendo i rischi e i costi associati al cambio di tecnologia. Si pensi anche alle gare di appalto per la Pubblica Amministrazione: sarà più facile selezionare una tecnologia, sviluppare nuove applicazioni, con la consapevolezza di non dover necessariamente invitare successivamente quell’unico fornitore di graph database già vincitore di precedenti gare in passato. GQL in questo contesto abilita una maggiore competizione, a tutto vantaggio della Pubblica Amministrazione che ne beneficerà con costi di aggiudicazione più bassi.
- Sviluppo di tool e applicazioni multi-database: GQL favorirà la creazione di strumenti e applicazioni compatibili con diversi database a grafo. Questo stimolerà l’innovazione nel settore e offrirà più opzioni agli utenti finali perché i system integrator e le aziende che sviluppano software avranno un mercato potenziale molto più ampio e non limitato ad uno specifico graph database.
- Stimolo alla ricerca e all’innovazione: i graph database e gli algoritmi di graph analytics derivano per larga parte dalla Teoria dei Grafi, un ramo della Matematica. Già oggi la ricerca accademica sui graph database ha portato a grandi innovazioni. Uno standard comune come GQL faciliterà la ricerca accademica e industriale nel campo dei database a grafo accelerando l’innovazione in questo settore.
GQL promette di unificare il panorama frammentato dei linguaggi di query su grafi, offrendo vantaggi significativi. Ricky Sun, founder e CEO di Ultipa contattato da Agenda Digitale in merito a GQL ha affermato che: “l’introduzione di GQL rappresenta un punto di svolta significativo nell’evoluzione dei database. Questo sviluppo presenta un’opportunità grandissima per tutti i fornitori di graph database, compresa Ultipa, di accelerare ulteriormente l’innovazione. Ai lettori di Agenda Digitale ho il piacere di annunciare in anteprima che con la nostra prossima release di Ultipa Graph, prevista per la fine settembre, rilasceremo il supporto per GQL, permettendo da subito ai nostri clienti e partner di cogliere i benefici del nuovo standard”
Adozione del nuovo linguaggio
Ad oggi, solo poche aziende hanno implementato lo standard GQL o lo stanno utilizzando. Tuttavia, come già avvenuto con SQL, è lecito attendersi una diffusione completa da parte di tutti i principali graph database vendor. Lo standard definisce in modo preciso il modello dei dati, la sintassi e le funzionalità di base, lasciando spazio a estensioni opzionali. È probabile che i primi prodotti conformi allo standard GQL supporteranno le sole funzionalità obbligatorie, con le estensioni opzionali che verranno introdotte gradualmente.
L’implementazione delle funzionalità minime richieste dallo standard non è banale e richiederà ancora diversi mesi. Il nuovo standard è infatti il frutto di una vasta collaborazione tra aziende ed esperti del settore, che hanno cercato di unificare le diverse implementazioni esistenti. I graph database presentano infatti una grande varietà di approcci alla gestione dei dati, spaziando da modelli completamente schemaless (come Neo4j) a modelli strutturati (come Ultipa). Malgrado GQL sia stato progettato per adattarsi a questa diversità, il supporto da parte dei database vendor richiede comunque tempo. Inoltre, nonostante l’entusiasmo generale, alcuni vendor potrebbero ritardare l’implementazione, per continuare a fare leva sugli investimenti pregressi in linguaggi come Cypher e openCypher.
In attesa di una diffusione più ampia, è fondamentale che le organizzazioni che oggi hanno necessità di un graph database richiedano ai vendor una roadmap chiara per il supporto a GQL, valutando attentamente il livello di supporto previsto. In particolare, nelle gare d’appalto della Pubblica Amministrazione, è auspicabile che vengano specificati dei requisiti minimi che possano essere soddisfatti da più vendor, includendo il supporto a GQL. In questo modo, si promuove quella competizione tra le aziende che permette all’amministrazione pubblica di ottenere il prodotto più adatto alle proprie esigenze, ad un costo complessivamente più basso. Per la Pubblica Amministrazione, questo significa potersi aprire idealmente a lavorare con diversi vendor nel lungo periodo, senza per questo dover apportare grandi modifiche al codice GQL eventualmente già sviluppato.
Anche per le aziende che sviluppano software è importante monitorare attentamente l’evoluzione del mercato e utilizzare il nuovo standard prima possibile. Questo è quello che già stanno facendo alcune aziende italiane. Per esempio, la società Enablit utilizza un graph database per implementare un servizio innovativo per il mondo legale. Quest’azienda ha importato centinaia di migliaia di documenti legali, estratto delle informazioni che ha organizzato in un grande grafo. Enablit si sta preparando ad utilizzare GQL per eseguire query complesse ed estrarre da dati non strutturati nuove informazioni, altrimenti impossibili da catturare.
Un’altra azienda italiana, Neperia Group ha integrato un graph database, per fornire un’analisi ancora più approfondita del codice sorgente dei clienti finali. Neperia Group si sta preparando già oggi ad utilizzare il linguaggio GQL per eseguire query sul graph database e comprendere, anche in assenza di documentazione, come il codice sorgente dei clienti finali accede in scrittura ai database aziendali. Si pensi ad esempio al codice Cobol, sviluppato anche decine di anni fa, ancora in uso in molte grandi aziende e di cui non sempre è facile reperire la documentazione. In questo caso, il graph database permette di evidenziare quali sono le funzionalità più critiche implementate nel codice sorgente, tracciando come le operazioni CUD, Create, Update e Delete accedono alle diverse tabelle di un database. Quest’analisi fornisce degli strumenti innovativi per analizzare gli impatti, rischi e costi della modernizzazione del codice sorgente esistente.
Il nuovo standard GQL rappresenta dunque un’importante opportunità per tutti il mercato. Non solo fornisce dei vantaggi forti ai clienti finali, ma offre anche nuove prospettive di crescita e innovazione per l’intero mercato dello sviluppo software. Chi saprà cogliere rapidamente queste opportunità potrà trasformarle in un vantaggio competitivo e in una nuova fonte di fatturato significativa, aprendo così nuove strade per il successo, su un mercato non solo nazionale.
Note
[1] Documentazione ufficiale dello standard GQL rilasciata da ISO, aprile 2024, https://www.iso.org/standard/76120.html
[2] Sito non ufficiale dei gruppi di lavoro che hanno collaborato alla creazione dello standard GQL, https://www.gqlstandards.org
[3] Lista dei principali graph database vendor, https://it.wikipedia.org/wiki/Base_di_dati_a_grafo
[4] Annuncio della disponibilità di Google Spanner Graph, agosto 2024, https://cloud.google.com/blog/products/databases/announcing-spanner-graph
