Molti informatici hanno sentito parlare dei sistemi NoSQL, ossia quelle base dati con struttura non-relazionale. Cosa significa di preciso? Significa che in un database non esistono più le relazioni logiche tra due tabelle (ad esempio tra la tabella utenti e quella veicoli), bensì una filosofia diversa utilizzata per il disegno di banche dati.
La metodologia noSQL (ricordiamo che SQL significa Structured Query Language) è rappresentata da tanti progetti di cui molti open source e alcuni dei quali applicati in contesti di reale importanza: per scopi governativi, di intelligence, o nelle principali multinazionali del mondo.
Tuttavia, attorno al noSQL, sta generandosi un’attenzione forse non proprio corretta che sta portando qualche fraintendimento concettuale. Vorrei proporre quindi una riflessione diversa, critica, forse polemica ma comunque una riflessione, sulla differenza tra il metodo relazionale e quello non relazionale (badate perché sto parlando di metodo).
Struttura o non struttura
All’interno di una base dati di un negozio di noleggio auto, la tabella clienti e la tabella veicoli, sono logicamente collegate. Un cliente può noleggiare più auto e di conseguenza ci si aspetta che le due tabelle rappresentino questa relazione.
In un database noSQL questa relazione non viene espressa tramite due tabelle, bensì tramite un documento. Ossia una sorta di scheda cliente che riporta al suo interno tutti i dati anagrafici e anche le auto utilizzate.
Tenete conto che sto semplificando molto ma, per aumentare un po’ la chiarezza, è opportuno fare un esempio leggermente diverso.
Siete fuori dalla porta di casa: una persona vi mette in mano una forchetta e vi dice di metterla al suo posto. Voi entrate in cucina, aprite il cassetto delle posate e la mettete a posto. Cosa avete fatto? Avete sistemato un oggetto, in base alla sua tipologia. Pertanto avete selezionato un cassetto specifico che raccoglie oggetti di quel tipo. E se vi dicessi che il cassetto delle posate non esiste? Che esiste un cassettone unico in cui potete mettere sia le posate, che gli altri oggetti? Vi piacerebbe?
Diciamo che parlare di noSQL significa rappresentare qualcosa di simile a questo concetto. Attenzione però, il mio esempio è volutamente polemico. Facciamo un altro esempio, più equo e onesto. Immaginate che fuori dalla porta di casa, invece di una forchetta, vi venga dato un oggetto generico. Probabilmente il cassetto nel quale non lo mettereste sarebbe quello delle posate ma, potreste aprire un cassetto qualsiasi e custodirlo lì dentro.
Cosa fa la differenza? Ovviamente la tipologia di oggetto.
Ebbene nel caso della scelta tra banche dati strutturate e non strutturate, la scelta dovrebbe essere dettata dall’impiego del dato. Analisi statistiche massive, operazioni di caching, analisi quantitative, possono essere pensate su sistemi non strutturati, su sistemi dove l’estrazione del singolo dato non è prioritario in confronto all’analisi complessiva dei risultati.
I dati strutturati, che tra l’altro sono nati dopo quelli non strutturati, hanno un impiego ben preciso: quello di ritrovare un dato specifico in mezzo a tanti altri. Con le relative relazioni e proprio grazie ad esse.
Un mio collega, persona molto attenta al mondo dell’intelligence, mi ha sottoposto un quesito legato al fatto che i principali sistemi d’indagine statunitensi si basano su soluzioni noSQL. Sicuramente questo consente di inserire all’interno di un’unica collection (l’equivalente di un tabella) dati di struttura diversa. Potremmo avere dati provenienti da Facebook, dal sistema sanitario nazionale, da Twitter. Ciascuno con il proprio schema dati. Ognuna di queste schede (appunto “documenti”) contiene dati differenti. Il problema infatti è proprio questo.
A ridosso del caso Snowden, un magistrato italiano di cui onestamente non ricordo il nome, spiegava l’inutilità di “tracciare” e “sorvegliare” tutto perché, spiare tutto, significa non spiare niente. Essendo la mole di dati eccessivamente alta, la possibilità di arrivare ad un dato specifico si assottiglia anche se venissero utilizzati sistemi di filtraggio molto evoluti. È un approccio ad un problema che, personalmente, considero poco proficuo ma di cui riconosco la validità poichè le fonti da monitorare sono troppo eterogenee. E qui nasce il vero quesito.
Dimmi cosa devi fare, ti dirò cosa devi usare
La tecnologia adottata dovrebbe seguire due criteri:
- Scopo d’uso.
- Obiettivi che si intende raggiungere.
Monitorare le comunicazioni internet, seppur eterogenee, è possibile e fattibile con un sistema basato su noSQL e ciò risulta di più rapida e semplice implementazione piuttosto che con un insieme di database strutturati.
Questo ragionamento, però, funziona solo fino al momento in cui decidiamo di non voler fare analisi troppo capillari perché, in tal caso, potremmo trovarci male con un DB senza struttura.
Eppure, permettetemi di fare un po’ di polemica, a me sembra che la moda noSQL (perché se ne parla troppo e male), spesso derivi dalla volontà di non disegnare il tanto amato/odiato diagramma E-R (Entità Relazioni). Questo diagramma consente di sapere in anticipo (in fase di progettazione) quali sono le tabelle, i campi di tabella e le relazioni che sussistono all’interno di un database relazionale. Disegnare un diagramma E-R costa molto tempo e richiede una certa bravura. E se si potesse saltare questo passaggio?
Se l’approccio fosse questo, magari motivato da una maggiore velocità e creatività di realizzazione della banca dati, vi confermo che sarebbe un approccio sbagliato.
Anche dal punto di vista prestazionale il quadro non cambia, entrambe le soluzioni offrono capacità di scalabilità (anche SQL può essere suddiviso in cluster). Mentre da diversi confronti tra DB relazionali e DB non relazionali, è emerso che se la struttura del DB relazionale venisse costruita adeguatamente, le interrogazioni (query) per il recupero delle informazioni, risulterebbero più rapide che in un DB non relazionale. In fondo è comprensibile. Un conto è cercare 1 cosa all’interno di una specifica tabella (1 forchetta nel cassetto delle posate). Un conto è cercare un oggetto all’interno di tutti i cassetti.
Sono opinioni ma…
Sono opinioni personali, intendiamoci, ma c’è un fondo di verità. La realizzazione di uno schema entità relazioni, definisce un lavoro progettuale che viene fatto a monte e spesso ripaga il cliente attraverso risultati precisi e prestazioni elevate. Le tecnologie noSQL dovrebbero essere ad uso ponderato su specifiche finalità mentre, fin troppo spesso, se ne sente parlare come il futuro dei data base e questo non è corretto.
La grande potenzialità del noSQL è quella di creare delle vere e proprie collezioni di dati, tutte radicalmente diverse tra loro ma, al tempo stesso, tutte potenzialmente importanti all’interno di analisi quantitative.
Resta però un concetto chiave: ogni tecnologia adottata richiede uno studio a monte senza il quale, probabilmente, si fallirà il raggiungimento di qualsiasi risultato.
