Database NoSQL, cosa li differenzia dai DB relazionali o SQL e perché sono più adatti alle moderne applicazioni di Big Data analysis e di cloud computing
NoSQL non è un divieto di ingresso per i database relazionali. O meglio lo potrebbe essere in relazione all’applicazione che deve utilizzare il DB, in quanto vi sono casi d’uso in cui i database relazionali non sono di certo adatti allo scenario da sviluppare, mentre dovrebbero essere utilizzati le basi dati destrutturati, definite in gergo tecnico NoSQL.
Al di là della facile ironia che si possa fare sul termine scelto dagli esperti IT per questa tipologia di database, in realtà la nascita e il recente sviluppo dei DB NoSQL si è rivelato di importanza fondamentale per garantire la crescita di tutta una serie di applicazioni ricche di contenuti e spesso distribuite agli utenti tramite Internet.
Cerchiamo di capire insieme quali differenze contraddistinguono un database relazionale da uno NoSQL e perché in determinate situazioni è più corretto scegliere quest’ultima forma di conservazione dati.
Un database relazionale è composto da tabelle che sono messe in relazione fra loro attraverso le chiavi esterne, meglio note come foreign keys. In pratica, i dati vengono spalmati in differenti tabelle che contengono righe e colonne, ossia tuple di dati che prendono senso se collegati ai rispettivi attributi (intestazioni delle colonne), assumendo così la natura di informazioni. In questo modo, anche se i dati descrivono uno stesso oggetto, devono comunque essere memorizzati in tabelle differenti, a meno di non prevedere tabelle molto grandi, quasi mai consigliate perché di difficile gestione anche con sistemi computazionali molto potenti.
Ogni volta che si svolge un’interrogazione, i dati devono essere raccolti dalle differenti tabelle e combinati fra loro per fornire il giusto risultato all’applicazione che ne ha fatto richiesta. Lo stesso vale per le operazioni di cancellazione, inserimento e aggiornamento. Ogni volta, il linguaggio SQL deve verificare le relazioni fra i differenti dati residenti nelle differenti tabelle e applicare le modifiche richieste, preservando l’integrità del DB da eventuali corruzioni (un problema non poco comune nei database relazionali).
Database NoSQL senza tabelle!
I database NoSQL sono progettati in maniera differente: i dati non sono conservati in tabelle e, soprattutto, non sono spalmati in differente strutture logiche, ma sono raccolti, aggregati e conservati in documenti la cui semantica risponde al formato JSON. Ogni JSON è capace di raccogliere in un unico documento/oggetto tutti i dati sparsi fra le tabelle del database relazionale, in modo che il documento possa essere trattato dall’applicazione come un vero e proprio oggetto. Così, si evitano i passaggi di aggregazione delle informazioni tipiche delle elaborazioni SQL, in quanto il lavoro è già stato svolto in precedenza.
Si ottengono migliori performance e prestazioni su tutte le operazioni che richiedono l’intervento del DB e lo svantaggio è la duplicazione delle informazioni dovuta all’aggregazione delle stesse. In realtà, i costi sempre meno proibitivi dei sistemi di storage rendono questo svantaggio poco importante, a fronte della flessibilità offerta dal modello NoSQL.
Database NoSQL senza schema…
Un’altra caratteristiche che differenzia i database relazionali da quelli NoSQL è la schematizzazione. Per realizzare qualsiasi tabella di qualsiasi database relazionale, è necessario definire a priori uno schema (noto come entità-relazione), nel quale si definiscono anche i singoli attributi delle tabelle per la corretta interpretazione dei dati conservati.
Cambiare in corsa questo schema, magari introducendo nuovi attributi, è problematico e, spesso, sconsigliato proprio per evitare problemi di corruzione al DB. Questa limitazione rende i database relazionali molto poco adatti alle trasformazioni dei Big Data e alla scalabilità richiesta dalle condizioni di Big User e dalle tecnologie di cloud computing.
A risolvere il problema è il NoSQL che è detto schemaless, ossia privo di qualsiasi schema definito a priori, permettendo così di inserire nei documenti JSON tutti i campi necessari, senza necessità di definirli. In questo modo, i dati inseriti possono cambiare in qualsiasi momento per arricchire le applicazioni, senza rischi per l’integrità del DB.
Da questa caratteristica deriva che i database relazionali sono poco adatti a incorporare velocemente nuovi tipi di dati e sono sconsigliati per la conservazione di dati semistrutturati o non strutturati. Al contrario di quelli NoSQL che, invece, si rivelano utili in entrambi i casi.
Insomma, se vogliamo dare vita a un’applicazione scalabile senza problemi e a costi contenuti, distribuibile nel cloud computing e le cui informazioni devono essere sottoposte ad analisi dei Big Data, la scelta giusta risiede nei database NoSQL.