SABD - 04 - NoSQL I

Installare prima della lezione i diversi container ripotati per effettuare delle prove durante la lezione stessa e risolvere piccoli esercizi.

Links container: 031419_hands-on.txt

L'acronimo ACID serve per sintetizzare le seguenti importanti caratteristiche che un tipico DBMS relazionale deve offrire:

• Atomicity: Tutte le operazioni che fanno parte di una transazione vengono eseguite in modo atomico: o vengono eseguite tutte o nessuna. Le transazioni seguono quindi il principio del tutto o niente.

• Consistency: Il database relazione è in uno stato consistente sia prima che dopo l'esecuzione di una qualsiasi transazione.

• Isolation: Le transazioni non possono vedere dei cambiamenti di cui non è stato effettuato il commit all'interno del DB. Dunque il comportamento di transazioni concorrenti è ben definito e il risultati di transazioni che non vengono completate non sono visibili alle altre transazioni.

• Durability: I cambiamenti apportati da transazioni completate sono persistenti nel tempo e non vengono persi anche in situazioni critiche di crash di sistema o interruzione dell'alimentazione che potrebbero portare a glitch nella memoria RAM.

Question: L'atomicità include la consistenza?

Answer: No, l'atomicità non include la consistenza in quanto la consistenza è vista rispetto ai vari stati in cui il DB si può trovare, mentre l'atomicità è vista solamente rispetto alle operazioni che compongono la transazione.

I vincoli che troviamo in un tipico DMBS relazionale sono i seguenti:

• Domain contraints: Permette di restringere il dominio dei possibili valori per un dato campo.

• Entity integrity contraints: Il valore della primary key non può essere nullo.

• Referential integrity contraints: I vincoli di integrità referenziali ci permettono di mantenere la consistenza tra tuple che appartengono a due relazioni differenti, imponendo che il valore che un determinato attributo ha in una relazione debba esistere come valore che un altro attributo ha in un'altra relazione.

• Foreign key: La foreign key è utilizzata per fare dei riferimenti incrociati tra relazioni differenti e si deve trovare in una relazione di matching con la chiave primaria di un'altra relazione.

I vantaggi nell'utilizzo di un tipico DBMS relazionale derivano dal fatto che il modello di consistenza garantito è ben definito. In generale, dato che i database relazionali sono stati studiati per più tempo, si conoscono molto bene e si hanno delle solide basi teoriche che ne formalizzano la struttura e il comportamento.

In generale i DBMS relazionali sono molto suited per le applicazioni OLTP (OnLine Transaction Processing).

Gli svantaggi nell'utilizzo di un DBMS sono i seguenti:

• La scalabilità risulta essere molto limitata. Tipicamente un DBMS non può scalare su un ambito geografico e abbiamo un numero minimo di repliche (2 o 3) per garantire la tolleranza ai guasti in un ambito geografico.

• Supporto limitato per strutture dati che possono variare in modo dinamico nel tempo.

• Integrazione di dati da differenti RDBMS può essere molto pesante e difficile.

Per fare scalare un RDBMS abbiamo le seguenti due principali soluzioni:

• Replicazione: Abbiamo vari server ciascuno dei quali contiene una porzione del DB. Questa soluzione richiede di risolvere il problema di mantenere la consistenza dei dati tra i vari server.

  

  Il modello primary backup con l'architettura master/worker ci permette di avere un forte modello di consistenza.

  Tramite la replicazione siamo in grado di eseguire operazioni di lettura in modo concorrente su tutte le repliche del DB, mentre le operazioni di scrittura sono effettuate solo dalla replica master, che si occupa poi di aggiornare le varie repliche workers.

  La replicazione ci permette di scalare bene sulle operazioni di lettura, mentre le operazioni di scrittura rappresentano il collo di bottiglia.

• Sharding: L'idea è quella di partizionare i dati tra differenti server. È possibile poi distribuire richieste che fanno riferimento a shard diversi su diversi server.

  Il limite dello sharding è il fatto che non possiamo eseguire le transazioni che coinvolgono molteplici partizioni.

  Una forma di sharding può essere ottenuta con il consistent hashing, che consiste nell'utilizzo di una hash function per hashare sia i dati che i nodi e mapparli nello stesso namespace.

  

Notiamo in ogni caso che la scalabilità che si ottiene risulta essere molto costosa e inefficiente.

Le principali caratteristiche dei data stores NoSQL cercano di superare le limitazioni dei database relazioni, e sono:

• Scalabilità orizzontale: All'aumentare il numero di nodi che compongono il sistema le prestazioni aumentano con un andamento simile a quello lineare tramite uno sharding tra molteplici nodi.

  Notiamo che il sharding nei datastore NoSQL non crea troppi problemi di performance in quanto tipicamente i datastore NoSQL hanno un supporto limitato per le transazioni.

• Supporto per dati flessibile: Gli schemi di dati utilizzati sono molto più flessibili da quelli presenti nei database relazioni.

  In particolare non richiediamo che tutti i valori di tutte le righe devono essere impostati con un table schema. Le righe della stessa entità possono infatti avere un numero differente di colonne.

• Disponibilità elevata: I datastore NoSQL forniscono una disponibilità elevata, in quanto i dati possono essere presenti in vari nodi, o come nel caso di Cassandra possono essere distribuiti in modo geografico.

• Architettura shared-nothing

  Osservazione: Una eccezione a questo è neo4j, che è un database a grafo, che però presenta delle limitazione rispetto alla scalabilità.

• No operazioni SQL complesse: Eliminazione delle operazioni SQL più complesse, come l'operazione di JOIN.

• Modelli di consistenza deboli: Nei datastore NoSQL spesso si compromette la reliability per la performance. Il modello di consistenza garantito è infatti un modello di consistenza debole (eventually consistent).

  Osservazione: Il CAP Theorem ci dice che un sistema di database distribuito può avere solamente due caratteristiche tra le seguenti tre: consistency, availability e partition tolerance. I datastore NoSQL dunque, scegliendo l'availability e la partition tolerance, non possono ottenere anche la consistency.

Le proprietà BASE sono una versione più rilassata delle proprietà ACID. Infatti, mentre le proprietà ACID si basano su una visione pessimistica, le proprietà BASE si basano su una visione ottimista in cui è ammessa l'occorrenza di conflitti che vengono risolti tramite opportune politiche.

L'acronimo BASE sta per:

• Basically Avaiable: L'intero sistema è disponibile la maggior parte del tempo, anche se potrebbe esistere un sottosistema temporaneamente non disponibile.

• Soft state: Contrapposto alla durability (D in ACID), significa che non vi è la stessa persistenza garantita come nell'approccio ACID.

• Eventual Consistency: Modello di consistenza finale ci garantisce che le diverse copie presenti nel sistema convergeranno ad uno stato consistente all'interno di una finestra temporale. All'interno di questa finestra temporale però utenti diversi potrebbero vedere valori diversi per lo stesso dato.

Le politiche utilizzate per risolvere i conflitti possono andare dall'aggiornamento condizionale (controllo del valore prima di aggiornare) all'utilizzo di timestamp basato su clock vettoriale per capire la scrittura più recente (last write wins).

Il cambiamento nella gestione della consistenza è stato uno dei più grandi cambiamenti dal mondo dei datbase tradizionali, che hanno sempre offerto un forte modello di consistenza.

La maggior parte (non tutti) dei sistemi NoSQL sono sistemi di tipo AP (ovvero che scelgono l'availability e la partition tollerance del teorema di CAP), in cui il modello di consistenza offerto è rilassato (eventual consistent).

Osservazione: Alcuni sistemi NoSQL, come Cassandra, ci permettono di controlare il protocollo utilizzato per implementare il modello di consistenza utilizzato.

I datastore NoSQL riescono quindi a scalare rispetto al numero di utenti.

Alcuni vantaggi nell'utilizzo di datastore NoSQL sono:

• Scalabilità

• Disponibilità e tolleranza ai guasti.

• Presenza di molti prodotti open-source, che portano a dei costi di gestione ridotti.

• Notevole incremento di flessibilià.

Alcuni svantaggi nell'utilizzo di datastore NoSQL sono:

• La maggior parte dei datastore NoSQL non offre garanzie di tipo ACID. Questo comporta che i datastore NoSQL sono meno adatti per le applicazioni di tipo OLTP.
• Mancanza di modello di dati unico e mancanza di modello di storage unico.
• Mancanza di standardizzazione, in quanto manca u linguaggio unico come SQL e ogni applicazione ha il proprio linguaggio.
• Supporto limitato per operazioni di aggregazione.

Un modello di dati è un insieme di costrutti che vengono utilizzati per rappresentare le informazioni di interesse. Ad esempio, il modello relazionale rapresenta le informazioni utilizzando tabelle, che sono formate da colonne e righe.

Un modello di storage invece è il modo in cui il sistema che si occupa della gestione del data store memorizza e manipola i dati internamente.

Tipicamente un modello di dati è indipendente dal modello di storage utilizzato per implementarlo.

Andiamo adesso a vedere i vari modelli dei dati NoSQL che sono stati definiti negli ultimi dieci anni. Volendoli ordinare in base alla complessità, troviamo la seguente struttura:

• Aggregate-oriented models:
  • Key-value
  • Document
  • Column-family
• Graph-based models

Per aggregato si intende il fatto che le unità prese in considerazione possono avere delle strutture complesse e ricorsive.

Si basa sulla aggregate pattern nel Domain-Driven Design.

L'aggregato viene visto come una unità rispetto alle operazioni di manipolazione dei dati e la gestione della consistenza.

Notiamo che il supporto delle transazioni ACID è garantito solo all'interno di un singolo aggregato, e non sono quindi garantite per transazioni che coinvolgono più aggregati.

I modelli orientati ai grafi tipicamente supportano le proprietà ACID per le transazioni. Questo ha un costo sulle performance.