Dopo aver trattato la gestione dei dati distribuita in ambiente relazionale, affrontiamo i sistemi NoSQL.
Nel 1970 un ricercatore di IBM chiamato Codd pubblica un articolo intitolato “A relational model of data for large shared data banks” in cui presenta un modello di rappresentazione dati indipendente dall’implementazione. Si era passati dal modello gerarchico (in cui bisognava usare i puntatori per accedere ai dati) al modello relazionale. Questo passaggio è stato fondamentale per lo sviluppo del mondo dell’informatica, un mondo dove l’hardware dedicato allo storage era estremamente costoso, estremamente poco capiente (nel range di pochissimi megabyte) e logisticamente parecchio ingombrante. Il modello relazionale quindi era studiato in primis per questo contesto, proponendo strategie per la rappresentazione compatta dei dati.
Gli aspetti positivi del modello relazionale si possono comunque riassumere in:
è un modello molto ben definito, con il principio della minimizzazione, in merito allo spazio, e il principio della closed world assumption, ovvero tutto quello che l’applicazione deve sapere è nel database e a tal fine si ha anche l’uso del NULL value per:
Quindi il modello relazionale è una sorta di modello chiuso che contiene tutto il necessario ed era un modello ragionevole in un contesto come quello “pre anni 2000”, dove un’azienda tipicamente necessitava solo di informazioni interne all’azienda stessa (non c’erano le informazioni dei social network etc…, infatti, di fatto, non esiste più la closed world assumption)
si hanno circa 35 e più anni di sviluppo in sicurezza, ottimizzazione e standardizzazione. Da questo punto di vista si ricorda l’uso delle proprietà ACID che comunque rendono ancora valido il modello anche nel 2020. Inoltre ormai si hanno talmente tante informazioni memorizzate tramite il modello relazionale che le aziende sono restie a cambiare modello (a causa dei rischi di perdita dei dati durante un porting, anche dati dal fatto che i db preesistenti sono enormi, considerando che i dati persi non sono recuperabili potenzialmente, e meno di repliche)
è ben conosciuto, è studiato anche nelle scuole e università
è comunque la scelta migliore per diversi casi d’uso
Si hanno però anche delle limitazioni per il modello relazionale, come ad esempio:
il fatto stesso di essere un sistema chiuso, quasi per gli motivi descritti nei vantaggi, può anche essere un aspetto negativo, infatti:
i database relazionali sono difficili da modificare dal punto di vista schematico tramite alter table. Cambiare gli schemi è complesso e comporta il fermo del database;
per garantire le proprietà ACID nei sistemi transazionali e per poter garantire il 2PC si ha un limite fisico alla scalabilità. Dopo un certo punto di crescita i costi di organizzazione rendono impossibile l’esecuzione dei protocolli che garantiscono ACID, in ambiente distribuito.
Oggigiorno ci sono varie applicazioni, legate in primis ai social network, per le quali è impossibile mantenere certi protocolli. Il problema della scalabilità è uno degli aspetti più limitanti, specialmente in ottica big data (anche se vedremo che le alternative non relazionali coprono casi d’uso anche oltre il solo ambito dei big data).
I database relazionali si prestano bene alle scale out (scalabilità orizzontale) (semplicemente aumentando l’hardware a disposizione, arrivando a costi esorbitanti e fino al punto in cui si raggiunge il limite tecnologico) ma pochissimo allo scale up (scalabilità verticale) (che comporterebbe non l’acquisto di un nuovo hardware intero ma solo di una parte di esso, a prezzo più basso con hardware detto in gergo comodity, magari per avere più dischi etc. . ., ma hardware dedicato storicamente ai db relazionali non prevede questa cosa). Oggigiorno si hanno sempre più spesso le architetture a microservizi (che “implementano” bene lo scale out)
il time in market, ovvero il tempo in cui un’applicativo resta in commercio, è sempre più ridotto (spesso, per esempio, un videogioco ha una vita anche inferiore ad un anno) portando a rendere obsoleto il processo in cui normalmente si integrano i db relazionali. Anche il time to market, ovvero il tempo di preparazione, è ridotto.
Oggigiorno lo standard dal punto di vista hardware è drasticamente cambiato con dischi di capienza enorme (nell’ordine dei terabyte per qualche decina di euro). Il rapporto costo-GB è crollato rispetto a pochi anni fa. Il contesto storico è quindi cambiato e in tal senso anche il modello per la rappresentazione dei dati sta cambiando e sta cambiando anche la scelta tra spazio e tempo, non essendo più la prima una grossa problematica ed essendo la seconda di grande interesse, dovendo rispondere il più in fretta possibile alle interrogazioni.
Sulle slide un elenco dei vari step storici.
Il termine NoSQL è stato coniato da Carlo Strozzi nel 1998 quando si inventa una sorta di API per Linux per accedere ai dati relazionali senza usare SQL. Il termine è stato ripreso nel 2009 con la “logica” Not Only SQL dopo che per circa 9 anni, a partire dal 2000, erano nati nuovi modelli, a grafi, a documenti etc… (da parte di Amazon, Google, Facebook etc. . .).
Quindi NoSQL è un’insieme di modelli di rappresentazione dati, con relativi software di gestione.
Si hanno 3 caratteristiche fondamentali: