I database di tipo relazionale memorizzano i dati in strutture fisse chiamate tabelle. Le tabelle sono legate tra di loro tramite relazioni. E’ possibile eseguire delle operazioni di lettura e scrittura sulle tabelle tramite le transazioni. Le transazioni possiedono le propriet`a ACID:
• Atomicit`a: la transazione `e atomica, perci`o la sua esecuzione non pu`o essere separata in pi`u parti
• Consistenza: l’esecuzione della transazione deve lasciare il database in uno stato consistente sia prima sia dopo la transazione. Nessun vincolo sui dati deve essere violato
• Isolamento: ogni transazione deve essere indipendente dalle altre, per- ci`o se una di esse fallisce questo non deve interferire con il corretto funzionamento delle altre
• Durabilit`a: dopo l’esecuzione della transazione i dati devono essere me- morizzati su un dispositivo di memoria
A questo approccio si contrappone l’approccio NoSQL, che promuove una mag- giore flessibilit`a del modello dei dati rispetto alla rigidit`a del modello relazio- nale. I database di tipo NoSQL infatti sono strutturati in modo diverso. Di seguito vengono illustrate alcune caratteristiche:
• I dati memorizzati non hanno una struttura fissa, difatti possono essere composti da campi che variano da entit`a a entit`a
• Un’entit`a contiene tutte le informazioni relative all’oggetto che essa de- scrive
• Non valgono le propriet`a ACID, bens`ı quelle BASE. Prima di introdurle `
e necessario introdurre anche il teorema CAP di Eric Brewer, che sostiene che in un sistema distribuito solo due delle seguenti propriet`a possono essere soddisfatte nello stesso momento:
– Consistency: tutti i nodi hanno gli stessi dati nello stesso momento – Availability: ad ogni richiesta deve susseguirsi necessariamente una
risposta
– Partition tolerance: il sistema continua a funzionare nonostante fallimenti e perdite di messaggi
Per soddisfare le propriet`a ACID `e necessario puntare su consistenza e partition tolerance, a discapito della disponibilit`a. Di seguito invece le propriet`a BASE, che puntano su disponibilit`a e partition tolerance, a discapito della consistenza:
– Basic Availability: la disponibilit`a di base `e sempre garantita grazie a una forte replicazione dei dati tra i vari nodi
– Soft state: lo stato potrebbe non essere consistente
– Eventual consistency: dopo un’aggiornamento dei dati, `e presente una finestra temporale in cui non `e detto che i client che accedo- no ai suddetti dati vedano gi`a il valore aggiornato. Questa forma di consistenza garantisce che se non sono stati fatti nuovi aggior- namenti ad un oggetto, gli accessi successivi ritorneranno l’ultimo valore aggiornato
Come si nota, si punta di pi`u a prestazioni, scalabilit`a e disponibilit`a dei dati, a scapito della consistenza. Si ritiene infatti che in contesti come le applicazioni web sia pi`u importante ottenere i dati il pi`u velocemente possibile, anche s ei dati non sono totalmente aggiornati
Entrambi gli approcci hanno vantaggi e svantaggi che vanno considerati prima di compiere una scelta. Di seguito vengono elencati alcuni vantaggi dell’ap- proccio NoSQL:
• Migliori prestazioni : dato che le entry contengono tutte le informazioni relative all’oggetto descritto, non `e necessario effettuare delle join per ottenerle (come invece accade per l’approccio relazionale). Pi`u la mole di dati `e grande pi`u il vantaggio in prestazioni cresce
• Dati non strutturati : `e’ possibile modellare con pi`u facilit`a dati non strutturati, dato che `e possibile inserire nel database entry strutturate in modi diversi. Per la stessa ragione `e pi`u facile gestire requisiti incerti e mutevoli
• Scalabilit`a orizzontale: se `e necessario bilanciare il carico, in un sistema NoSQL `e possibile scalare orizzontalmente (quindi suddividere i dati su pi`u server). Con il modello relazionale invece `e necessario scalare vertical- mente, non potendo suddividere i dati su pi`u server (`e quindi necessario aumentare la potenza dell’unico server)
Di seguito vengono invece elencati alcuni svantaggi dell’approccio NoSQL: • Duplicazione dei dati : proprio perch`e le entry contengono tutte le infor-
mazioni dell’oggetto descritto, verr`a effettuata una grande duplicazioni di dati che porta ad un utilizzo di memoria maggiore. Se ad esempio dobbiamo modellare dei prodotti che fanno parte di una certa categoria, dovremmo indicare la categoria in ogni entry. Con l’approccio relazio- nale invece andrebbe definita la categoria una volta sola in una tabella a parte. Va per`o considerato che il costo della memoria cala sempre di pi`u con il passare del tempo, quindi in molti casi questo svantaggio non incide pi`u di tanto
• Maggior numero di scritture: per lo stesso motivo di prima, cresce anche il numero di scritture. Se per esempio si vuole aggiornare i dati relativi alla categoria, questo andr`a fatto per ogni entry che contiene le informa- zioni della categoria, poich`e le informazioni sono appunto ripetute. Con l’approccio relazionale sarebbe sufficiente modificare una volta le infor- mazioni della categoria. Questo incide anche sulle prestazioni relative alle operazioni di update che risultano quindi pi`u lente
• Consistenza: `e pi`u facile che si verifichino errori e problemi di consistenza proprio perch`e `e possibile inserire nelle collezioni documenti con strutture diverse. Nell’approccio relazionale invece si pu`o definire strettamente il modello dei dati e questo porta a un maggiore controllo e rigidit`a
• Query complesse: se `e necessario effettuare query molto complesse (in particolare innestate) il tutto risulta pi`u complesso rispetto ad un lin- guaggio come SQL
A.6.1
MongoDB
MongoDB `e un DBMS open source di tipo NoSQL, e risulta attualmente il pi`u utilizzato di questa categoria. Dopo la sua installazione, si pu`o utilizzare tramite interfaccia a linea di comando, ma sono disponibili anche dei software di terze parti con interfaccia grafica che ne semplificano tantissimo l’utilizzo (come ad esempio RoboMongo).Di seguito vengono illustrate le caratteristiche principali di MongoDB:
• E’ orientato ai documenti. Il database `e composto da collezioni che con- tengono dei documenti (insiemi di coppie chiave-valore). I documenti vengono memorizzati in linguaggio BSON (Binary JSON), ovvero un’e- stensione del linguaggio JSON. Rispetto a JSON, in cui vengono memo- rizzate coppie chiave-valore, in BSON viene memorizzato anche il tipo di dato
• La chiave primaria dei documenti `e il campo id. Questo campo viene ge- nerato automaticamente da MongoDB. Questo campo `e di tipo ObjectID ed `e costituito da 12 byte:
– 4 byte per timestamp
– 3 byte per l’ID della macchina
– 2 byte per l’ID del processo di creazione del documento – 3 byte per il contatore incrementale
• Essendo NoSQL, i documenti possono avere struttura diversa tra loro, non devono seguire uno schema prefissato
• Sono supportate ovviamente le operazioni CRUD: – Create (insert)
– Read (find) – Update (update) – Delete (remove)
• Supporto per operazioni di aggregazione (in modo simile alla GROUP BY di SQL) grazie all’Aggregation Framework. L’aggregazione viene mo- dellata come una sequenza di operazioni sui dati. Le operazioni principali possono essere di tipo:
– Filtro: i dati vengono filtrati
– Trasformazioni : i dati vengono modificati
Oltre a questo si aggiunge la possibilit`a di ordinare i dati, raggrupparli e anche utilizzare degli operatori per effettuare calcoli (come ad esempio la media)
• Supporto ad operazioni di Map Reduce