Mentre vedevo i tipi di database, volevo provare a capire meglio le implicazioni di uno a grafo e ho trovato neo4j.
In un corso al politecnico, chiamato Knowledge Engennier, uno delle applicazioni era con il RDF, un modello per rappresentare connessioni, che è anche quello che viene implementato in Wikidata ( in riferimento al Linux day 2023 dove hanno mostrato come usarlo).
Ma quando conviene?
Mentre stavo provando a pensare a un caso pratico, ho iniziato a fare un corso su Linkedin Learning chiamato “Introducing neo4j” per capire meglio e questa è stata la frase che mia ha fatto capire dove avrei potuto sfruttrarlo efficacemente:
Exploring long connection chain”
E qui mi sono è subito venuto in mente quando hai una tabella con connessioni a se stessa e quindi ricorsiva.
E allora quali sono i casi d’uso per sperimentare localmente?
Se molti casi servono dati privati, quindi che non è facilmente replicabile.
Alcuni esempi sono le transizioni di una banca o nei social network per la raccomandazione di persone che si possono conoscere e dei contenuti.
Ho pensato a dati che possiamo avere tutti o, almeno, si possano generare da soli e qui mi è venuto in mente il primo caso pratico.
WordPress: Relazioni
Stavo guardando il mio sito web che, anche se non ha molti dati, si può già partire concettualemnte ad avere una piccola knowledge base.
Gli elementi che ho preso sono 3:
- Categoria
- Post
- Tag
Usando le API di WP (per esempio riferito ai Post), ho preso in formato JSON i dati e poi con uno script in Python li ho caricati su Neo4j ed è uscito questo:
E così di colpo vedo la rappresentazione grafica che collega tutti i miei elementi. Subito noto che la maggior parte è collegata ( visto che sono post relativi al mio lavoro ), ma alcuni in modo in cui non pensavo.
Principalmente le categorie sono quasi tutte staccate, come si può notare nella prossima immagine, tranne per un collegamento padre e figlio ( e un collegamento che potrei fare, tra Magento e PHP, in più anche WordPress e PHP, visto che fanno parte di questo macro gruppo):
MATCH (n:categories)
RETURN n
Ma se volessi vedere solo i post collegati fra di loro da almeno un tag, potrei fare un query apposta come la seguente:
MATCH (n:posts)-[]-(m:tags)
RETURN n,m
Oltre a usarlo personalmente, potrebbe essere utile sia per un utente che cerca tra i miei contenuti, per esempio aggiungendo anche altre informazioni semantiche, come per esempio i link all’interno del test riferiti sia ad altri post, sia all’esterno.
Altri casi possibili (con dati pubblici)
Mentre stavo ripensando ai dati bancari, mi è venuto in mente un caso particolare: la blockchain.
Usando Bitcoin (che stavo vedendo che attualmente è circa 500GB di dati), si può costruire il movimento delle transazioni, sia in ordine temporale, sia il giro di wallet.
Quando intendo anche in ordine temporale è perchè potrebbe interessarci solo le transazioni in uscita da un wallet dopo una data e dove ha interagito anche con altri, ma il suo passato potrebbe essere irrilevante, ma intanto lasciando la gestione di queste informazioni al DB.
Un caso, invece più da sviluppatore, è vedere le relazioni di dipendenza tra i pacchetti installati di un repository.
Alcuni come composer e npm hanno già il file con tutte le dipendenze da installare e quindi è più facile far vederle, ma ad esempio python con PIP, si potrebbe usarlo per far vedere quali sono i pacchetti in uso, aggiornando di volta in volta la knowledge base ed avendo un feedback veloce quando un repository che usa una dipendenza aggiornata o deprecata sia da modificare (soprattutto per un instanza privata di repository self hosted).
Invece, se si vuole tenere un albero genealogico (di cui in questo post facevo vedere un implementazione su WP), potrebbe essere utile per capire quanta distanza c’è fra i nodi, che percorso fa e soprattutto ottenere facilmente una visualizzazione fra di essi.
Ed infine, un caso che noto spesso quando leggo libri, sono le citazioni tra autori.
Quindi, inserendo ogni libro come un nodo e avendo un nodo per la citazione, si può trovare la rete di connessione che potrebbe aiutarci a comprendere meglio le informazioni di base su cui si appoggiano (che è simile anche alle pubblicazioni mediche e non).
Infine, tra amici, si può condividere le proprie letture e ottenere feedback su quale potrebbe essere un libro utile per comprendere meglio una tematica.
Conclusione
Se nel tuo applicativo c’è qualche caso d’uso in cui bisogna controllare una lista concatenata di elementi, potrebbe essere il caso di delegare la ricerca a un database a grafo come neo4j, così da permettere di avere tempi minori di risposta e anche trovare collegamenti che non ci si aspetterebbe.