Cronaca dal NoSQL Day 2013 di Udine

Loggia del LionelloVi ricordate quando il professore alle superiori vi martellava con la definizione del modello E/R? E all’università, il corso di basi di dati si ostinava a farvi giurare sulla Bibbia che non avreste avuto altro db se non un relazionale? Bene, come disse Galileo “eppur si muove”. Ebbene sì!

Grusp e PHP User Group Friuli, ci hanno dato prova che esistono, ed a volte sono migliori, i cosidetti database NoSQL. Il NoSQL Day, ha lo scopo di divulgare e far conoscere questo nuovo concetto di database il cui obbiettivo non è di sostituire completamente il paradigma SQL ma di svolgere dei compiti precisi e specifici in modo più performante e scalabile.

Il primo intervento è stato di Salvatore Sanfilippo, creatore e sviluppatore di Redis, che ha illustrato le perfomance di questo db in caso di singolo nodo che degradano invece in ambienti distribuiti. Infatti in questo caso bisognerebbe mantenere la consistenza dei dati, l’availabilty e la partition tolerance (CAP).

Il teorema CAP afferma che è impossibile per un sistema informatico distribuito fornire simultaneamente tutte le tre caratteristiche per cui occorre trovare un trade-off. Quindi Salvatore illustra come ha affrontato il problema per rendere Redis adatto ai sistemi distribuiti sviluppando Redis Cluster. Redis Cluster infatti implementa un sistema master/slave dove il client dialoga direttamente con un master in modo che dal punto di vista delle prestazioni è come se fosse un sistema singolo nodo ma l’availability sia più alta perché nel caso in cui il master vada down, tramite un algoritmo di elezione, viene sostituito il master scegliendo tra gli slave.

Altro intervento molto interessante è stato quello fatto da Stefano Valle poiché ha spostato il punto della questione dal modello dei dati (tipicamente modelli chiavi/valore, grafo, document o column) usato dal db NoSQL alle feature che ciascun DB ha e che possono essere più comode ed utili al caso da analizzare. Ovviamente ogni database NoSQL si sposta all’interno del CAP a seconda di quanto vuole essere affidabile, veloce e consistente per cui la scelta deve ricadere sul database che più si avvicina ai nostri bisogni in termini di queste tre variabili. Poi ci sono altre variabili in gioco come la scalabilità delle scritture in sharding (scrittura su più macchine in ambiente distribuito), flessibilità delle query e modello di distribuzione di dati.

Successivamente è stato presentanto da Nicola Iarocci il caso d’uso di Gestionale Amica, un tipico software gestionale per aziende che però ha dovuto evolversi per andare sul web e sul mobile. Per poter tenere sincronizzati tutti i diversi device che potevano connettersi al software hanno avuto bisogno di sviluppare una API e la loro scelta è caduta su MongoDB per la sua naturale capacità di usare il formato JSON come dato e quindi permette un più agevole scambio di dati tra i diversi device.

Il successivo intervento, a cura di Gabriele Bartolini, è focalizzato su PostgreSQL e sulle novità che la versione 9.3 ha portato tra cui il Foreign Data Wrapper che permette di creare ed utilizzare tabelle presenti su altri database come Oracle o database NoSql, l’introduzione di modelli di dati tipici dei database NoSql, la possibilità di usare linguaggi procedurali come PLProxy o PLV8, POSTGIS per l’uso di dati geografici.

E’ stata poi la volta di Luca Garulli che ha mostrato come deve cambiare il nostro punto di vista per utilizzare un graph database come Orient Db e quindi per modellare un database dove i record sono relazionati tra loro in diversi modi. Nel linguaggio SQL che tutti conosciamo le relazioni sono tecnicamente eseguite tramite delle JOIN che però impattano molto sulle prestazioni poiché sono calcolate ogni volta che vengono eseguite. In un graph database invece le relazioni sono semplicemente dei vertici che collegano un nodo in un grafo e sono dei dati che sono già contenuti nel database. Per cui se vogliono sapere, per esempio, quali sono le persone che vivono in una data città all’interno del mio database non dovrò fare delle join tra la tabella delle persone e quella delle città ma dovrò semplicemente interrogare il nodo della città che mi interessa e trovare tutti i vertici provenienti dai nodi persona che puntano a quella città in modo nettamente più veloce.

L’intervento di Marco Borromeo ci ha mostrato, con il caso d’uso di Kijiji, come è possibile aumentare le performance e migliorare il carico sul server affiancando ad un database MySQL un database NoSQL (in questo caso è stato utilizzato Redis) per un compito specifico.

Successivamente Alberto Eusebi ha mostrato l’analisi effettuata per realizzare i desiderata del cliente finale, cioè un software capace di gestire imponenti flussi di dati (raw data, immagini…); la loro scelta è ricaduta sul database Riak per le sue feature come il MapReduce e per la possibilità di utilizzo dei vector clock. Sono anche state mostrate le difficoltà incontrate durante l’uso di questo database poiché una non corretta operazione di tuning dell’ambiente distribuito può portare alcuni nodi a diventare instabili ed a far crollare tutta l’infrastruttura.

L’ultimo speak condotto da Matteo Collina ha mostrato come partendo da LevelDB e da Node.js hanno creato LevelUP il cui scopo è appunto quello di esporre le feature di LevelDB in stile Node.js. Le maggiori feature del prodotto è la leggerezza del db (può girare anche su browser), la velocità di esecuzione delle query, risultati sempre ritornati in ordine alfabetico e la possibilità di leggere e scrivere stream di dati con le primitive ReadStream e WriteStream. Molto simpatica la presenza di un tutorial interattivo, LevelMeUp, su NPM che è il sistema dove si trovano tutte le estensioni per Node.js

Ok, la terra sotto i piedi crolla, le tue certezze sono diventati dubbi, tutti i colpi di testa per migliorare una query per avere performance accettabili sono state vane?

No, alla fine di questa giornata siamo consci di poter utilizzare un approccio diverso per avere prestazioni migliori: affiancare al database esistente un database NoSQL più “comodo”, flessibile e performante per compiti specifici.

dai nostri inviati sul campo Luca e Francesco

photo by Giulio Volo

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *