Proprietà e Differenza tra database RDBMS e NoSQL

Proprietà e Differenza tra database RDBMS e NoSQL

RDBMS e NoSQL

La caratteristica principale dei database relazionali è quella di garantire la consistenza dei dati mentre, al contrario, i database NoSQL garantiscono una grande disponibilità a scapito della consistenza.
I database relazionali (indicati con RDBMS) si basano sulle proprietà ACID mentre i database NoSql si basano sulle proprietà BASE ovvero sul Teorema di CAP.

Proprietà e Differenza tra database RDBMS e NoSQL

Proprietà ACID

In ambito informatico un insieme di istruzioni di lettura e scrittura sulla base di dati viene definito transazione. Possiamo definire alcune proprietà che un DBMS dovrebbe sempre garantire per ogni transazione che vengono identificate comunemente con la sigla ACID, che deriva dall’acronimo inglese Atomicity, Consistency, Isolation, e Durability.

Che cosa sono le proprietà ACID dei DBMS in informatica

Atomicità

L’atomicità di una transazione è la sua proprietà di essere eseguita in modo atomico, ovvero al termine della transazione gli effetti di quest’ultima devono essere totalmente resi visibili oppure nessun effetto deve essere mostrato. Questa proprietà viene spesso garantita dal DBMS attraverso le operazioni di UNDO per annullare una transazione e di REDO per ripetere una transazione. Se questa proprietà viene rispettata il database non rimane mai in uno stato intermedio inconsistente, infatti un qualsiasi errore fatto prima di un commit dovrebbe causare un UNDO delle operazioni fatte dall’inizio della transazione.

Consistenza o Coerenza

Questa proprietà garantisce che al termine dell’esecuzione di una transazione, i vincoli di integrità sono soddisfatti. Infatti se questa proprietà viene rispettata il database si trova in uno stato coerente sia prima della transazione che dopo la transazione. Con un piccolo esempio possiamo capire meglio cosa intendiamo per consistenza. Consideriamo una transazione bancaria tra due conti correnti, il principale vincolo di integrità che la transazione deve rispettare è che la somma dei due conti correnti prima e dopo la transazione deve essere uguale. Se la transazione rispetta questo vincolo allora possiamo dire che è coerente/consistente.

Isolamento

La proprietà di isolamento garantisce che ogni transazione deve essere indipendente dalle altre, ovvero l’eventuale fallimento di una o più transazioni non deve minimamente interferire con altre transazioni in esecuzione. Quindi affinchè l’isolamento sia possibile, ogni transazione deve sempre avere accesso a una base di dati consistente. I livelli di isolamento principali sono 4:

  1. Read Uncommitted, che consente di eseguire transazioni in sola lettura, senza quindi bloccare mai in lettura i dati.
  2. Read Committed, prevede il rilascio immediato dei dati in lettura e ritarda quelli in scrittura.
  3. Repeatable Read, vengono bloccati sia i dati in scrittura che quelli in lettura ma solo sulle n-uple della tabella coinvolta.
  4. Serializable, vengono bloccate interamente gli accessi alle tabelle in gioco, spesso questo è un livello di isolamento inefficiente.

Durabilità o Persistenza

Questa proprietà garantisce che i risultati di una transazione completata con successo siano permanenti nel sistema, ovvero non devono mai più essere persi. Ovviamente c’è un piccolo intervallo temporale tra il momento in cui la base di dati si impegna a scrivere le modifiche e la scrittura di quest’ultime, questo intervallo è un vero e proprio punto debole e quindi dobbiamo sempre garantire, per esempio con un log, che non si verifichino perdite di dati dovuti a malfunzionamenti. Per garantire questa proprietà quasi tutti i DBMS implementano un sottosistema di ripristino (recovery), che garantisce la durabilità anche a fronte di guasti ai dispositivi di memorizzazione, per esempio attraverso l’uso di back-up su supporti diversi oppure journaling delle transazioni.

Terorema CAP

Il teorema CAP per i DBMS è stato pensato inizialmente da Eric A. Brewer (da cui il nome di Teorema di Brewer), fondatore di Inktomi e chief scientist di Yahoo!, docente di Informatica presso UC Berkeley. In particolare questo teorema afferma che per un sistema informatico distribuito è impossibile garantire tutte e tre le seguenti tre garanzie.

Che cos'è il terorema CAP dei DBMS in informatica

Coerenza

Un sistema è completamente coerente quando è in grado di garantire che, una volta memorizzato un nuovo stato nel sistema, questo è utilizzato in ogni operazione successiva fino alla prossima modifica dello stesso. Quindi, tutte le richieste effettuate tra uno stato e quello successivo, forniscono il medesimo risultato.

Disponibilità

Un sistema è completamente disponibile quando è sempre in grado di soddisfare le varie richieste oppure erogare i propri servizi.

Tolleranza alle partizioni

La tolleranza alle partizioni è definita come la proprietà di un sistema di continuare a funzionare correttamente anche in presenza di una serie di fallimenti dell’infrastruttura, fino a che l’intero network fallisca.

Approccio BASE

Osservando la rappresentazione grafica del teorema di CAP nella figura seguente possiamo notare che secondo la teoria di Cap è impossibile garantire contemporaneamente tutti e tre i principi del teorema. Supponiamo infatti che venga aggiornato un dato su un nodo A e che venga letto da un nodo B. Il nodo B dovrà rispondere con la versione più aggiornata del dato e questo per garantire il principio di consistenza. Il nodo B potrebbe richiedere del tempo in attesa del messaggio con il dato aggiornato e inoltre in un sistema distribuito c’è un’alta percentuale di possibilità che il dato venga perso violando così il principio di Availability. A sua volta se volessimo garantire contemporaneamente i principi di Consistency e Availability dovremmo non partizionare la rete violando il principio di Partition Tolerance.

Rappresentazione grafica del Teorema di CAP

Quindi, come dimostra il teorema appena descritto, nel caso dei sistemi distribuiti, risulta impossibile garantire la tolleranza completa al partizionamento perchè esiste sempre la possibilità che venga perso il collegamento tra 2 nodi. L’approccio BASE, introdotto da Eric Browers, autore dello stesso Teorema di Cap, rappresenta una buona soluzione a questo limite. L’acronimo indica le caratteristiche che un sistema deve garantire partendo dalle considerazioni che derivano dal teorema di CAP.

  1. (B)asically (A)vailable
    Il sistema deve garantire sempre la disponibilità dei dati.
  2. (S)oft State
    Il sistema può cambiare lo stato nel tempo anche se non sono state effettuate letture o scritture.
  3. (E)ventual consistency
    Il sistema può diventare consistente nel tempo, anche senza ricevere scritture grazie ai sistemi di recupero della consistenza.

Come possiamo notare dalla rappresentazione grafica del Teorema di Cap nella figura precedente abbiamo tre coppie di garanzie possibili:

  1. Consistency Availability (CA)
    I dati vengono mantenuti in maniera coerente in ogni nodo del cluster ammesso che i nodi siano disponibili. Non può accadere quindi che qualche nodo abbia i dati non aggiornati. La totale coerenza può ovviamente incidere in maniera negativa sulle performance per quel che riguarda in particolare la latenza e la scalabilità. Un’altra nota negativa è che si possono avere dei problemi nel caso in cui si venga a creare un partizionamento tra i nodi in quanto in casi estremi si può avere un disallineamento dei dati. Il sistema, quindi, deve essere in grado di rilevare eventuali partizioni nella rete e nel caso ce ne fossero interromperle tutte tranne una e risolvere i conflitti. Questo è il compromesso utilizzato più spesso dai RDBMS e da soluzioni come Oracle Coherence, Vertica e Aster.
  2. Consistency/Partition tolerance (CP)
    Questo compromesso permette di mantenere i dati in maniera coerente in tutti i nodi del cluster e garantisce la tolleranza di partizione. Lo svantaggio sta nel fatto che può venire a mancare la disponibilità perchè se un nodo va giù il sistema non è più disponibile. Quasi tutte le configurazioni prevedono un nodo che ha la funzione di master e gli altri da slave. Alcuni esempi di soluzioni che utilizzano questo compromesso sono: MongoDB, BigTable e Redis.
  3. Availability/Partition tolerance (AP)
    Questo compromesso garantisce continua disponibilità e tolleranza alle partizioni. Viene utilizzato ad esempio da soluzioni come Apache Cassandra, CouchDB e Riak. I nodi rimangono on-line anche nel caso in cui non riescano più a comunicare tra loro ma una volta che la partizione viene risolta, il processo di sincronizzazione deve risolvere eventuali conflitti. Non abbiamo la garanzia che i nodi abbiano tutti gli stessi dati con valori identici durante la partizione e la sua risoluzione. Questa tipologia di compromesso migliora le performance per quel che riguarda la latenza e la scalabilità che è più lineare.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *