Sempre più spesso si parla di NoSQL, ovvero database non relazionali. Ma di cosa si parla esattamente? Da dove nasce l'esigenza di queste basi dati flessibili e scalabili?
Cominciamo col dire che un database SQL si basa su relazioni tra i dati in esso contenuti: semplicemente, possiamo pensare di rappresentare i dati in tabelle le cui righe rappresentano le informazioni estratte da una situazione reale. Ovviamente questa rappresentazione dei dati deve essere sensata, ad esempio una tabella che astrae l'anagrafica degli utenti conterrà nome, cognome, indirizzo, username, password e via dicendo. Le informazioni devono essere frammentate su più tabelle, che poi vanno messe appunto in relazione tra loro (nell'esempio precedente, possiamo pensare di separare la parte relativa all'indirizzo in un'apposita tabella a parte: il collegamento tra le due avverrà semplicemente con un campo ID presente in entrambe), come nella figura seguente:
La frammentazione è necessaria in quanto tabelle troppo grandi in termini di campi in esse contenuti diventano di difficile gestione. Questa struttura è potentissima, consentendo di rappresentare e organizzare moli di dati estremamente grandi, con la possibilità di ricercare (interrrogare) record, inserirli e cancellarli in maniera estremamente rapida (a patto di realizzare ed utilizzare bene il tutto). Ovviamente, impone anche una serie di regole ferree sulle relazioni tra i dati e sui dati stessi, che devono essere organizzati in maniera rigida, dopo un'attenta progettazione.
Ma le applicazioni moderne, social e cloud in testa, hanno esigenze diverse, prima tra tutte la flessibilità. Questo ha dato una grossa spinta ai cosiddetti database NoSQL, ovvero non relazionali (ad esempio, MongoDB). I social network, ad esempio, necessitano di dover elaborare miliardi e miliardi di byte di dati alla volta, dovendo fornire risposte in tempi praticamente nulli (pensate alla ricerca di un utente su Facebook, è praticamente in tempo reale, iniziando a mostrare risultati già alla digitazione dei primi caratteri), e spesso dovendo adattare i dati dell'utenza nel tempo, tutte caratteristiche difficilmente ottenibili senza costi esorbitanti con soluzioni SQL.
In un database NoSQL i dati non sono più rigidamente organizzati in tabelle, ma in documenti, per cui l'informazione non risulta più suddivisa in strutture logiche (le tabelle), ma appunto aggregata come oggetto in un documento (che deve avere però una sua struttura interna interpretabile). L'applicazione che andremo a sviluppare considererà il documento come un oggetto, potendo quindi andare a valutare tutte le informazioni relative all'entità rappresentata in un colpo solo. In parole povere, andremo ad evitare tutto l'onere di dover interrogare il database più volte, risalendo le varie relazioni fino ad ottenere l'informazione cercata tipica dei database relazionali.
Non essendoci più le tabelle, il database NoSQL diventa flessibile, poichè non deve necessariamente seguire uno schema definito inizialmente in fase di progettazione: ad esempio, possiamo usare un semplice documento in formato JSON.
{
“ID” : 1,
“Utente” : “Utente 1”,
èèè
“Indirizzo” : “Indirizzo Utente 1”
}
Il vantaggio computazionale è fuori discussione: tutte le informazioni sono in questo documento, non serve andare ad interrogare varie strutture dati per ricostruire il tutto, anche se ovviamente le informazioni così sono molto più onerose in termini di storage (ma con il costo sempre minore dei Terabyte questo spesso non rappresenta un grosso problema), al contrario dei database SQL nei quali al crescere dei dati occorre maggiore potenza computazionale (e maggiore attenzione all'organizzazione dei dati stessi, ad esempio prevedendo indici per determinate interrogazioni). Anche un altro vantaggio è piuttosto ovvio: se devo aggiungere un campo "Paese" ovvviamente questa operazione è banale, basta aggiungere questo dato al file JSON visto prima, senza dover aggiornare null'altro. Anche in termini di scalabilità, ad esempio se si volesse aggiungere un nuovo server di elaborazione dei dati, la soluzione NoSQL non pone particolari problemi.
Alla prossima..