Sezione divulgativa IT – 5 – I due paradigmi “ACID” e “BASE”

I due paradigmi “ACID” e “BASE”

ACID e BASE? No, non è un post di chimica in inglese ma in italiano sui database.

 

Nel mondo d’oggi abbiamo una moltitudine di sistemi a supporto delle decisioni (DSO – Decision Support Object o DSS – Decision Support System) basati sui dati.

I loro dati tipicamente provengono da altri sistemi, quelli che – riga a riga, transazione per transazione – generano dati da analizzare successivamente; questi sistemi detti OLTP (OLTP – On Line Transaction Processing) pongono la massima cura affinché ogni singola interazione persona-dati generi la corretta manipolazione delle righe di dati coinvolte.

Che poi tali dati siano nella forma più strutturata possibile, quella di un database strettamente normalizzato o meno, è relativamente meno importante; i dati alla base vi sono.

Gli OLTP generano dati, i DSO consultano in modo massivo dati generati dagli OLTP.

Ora concentriamo il focus sull’uso del dato, sul modo in cui viene fruito – non generato, sostanzialmente differente tra un DSO ed un OLTP relazionale; vi sono talmente tante differente che alla base troviamo due diversi paradigmi due diversi standard.

Lo standard tradizionalmente adottato per sistemi dedicati all’elaborazione di transazioni affidabili, gli OLTP è riassumibile con l’acronimo ACID (Atomicità, Consistenza, Isolamento, Durabilità). I sistemi a supporto delle decisioni richiedono standard meno rigidi quando si utilizzino dati storici e statici, precedentemente generati da sistemi OLTP ed importati, questo standard è riassumibile con la parola BASE, in cambio ci sono vantaggi che elencheremo.

Da qui il facile gioco di parole tra acido e basico del titolo.

In chimica, il pH misura la basicità o acidità una soluzione acquosa in una scala da 0 (massima acidità) a 14 (massima basicità) ponendo a metà, con pH a 7 – neutro – l’acqua pura, distillata a 25 °C; gli studiosi di basi di dati hanno ripreso questa metafora creando il secondo – in ordine temporale e vedremo poi quando e come è stato introdotto – acronimo, il BASE, mettendolo in opposizione al primo ponendo l’accento su quanto i due paradigmi sottesi a tali acronimi siano distanti tra loro quando ci si concentra sul punto della gestione delle transazioni, in particolare sulla affidabilità di tale gestione.

Per inciso, ricordiamo che una transazione, in informatica, è una sequenza di operazioni raggruppate che può concludersi o con un successo o un insuccesso.

Esaminiamo il paradigma ACID – quello dei sistemi OLTP usati, ad esempio, dai gestionali di una tipica banca o assicurazione, – in modo più dettagliato ma sintetico, guardando quindi quali siano le caratteristiche logiche che il sistema deve garantire alle transazioni che manipolino i suoi dati:

  • Atomicità: significa che la transazione è indivisibile nella sua esecuzione, e che tale esecuzione deve essere o totale, completa oppure nulla, annullata, come se non fosse mai stata iniziata. In altre parole, di una transazione non sono accettate esecuzioni parziali.
  • Consistenza (o coerenza): significa che prima di iniziare una transazione il sistema è in uno stato internamente coerente e quando la transazione termina tale sistema deve trovarsi in un altro stato internamente coerente cioè senza violazione di vincoli di integrità della base dati stessa che genererebbero inconsistenza tra i dati distribuiti tra le varie tabelle.
  • Isolamento: significa che ogni transazione deve essere eseguita in modo isolato e indipendente da tutte le altre transazioni. Ogni transazione è indipendente dalle altre. L’eventuale fallimento di una transazione non deve influire con altre transazioni in esecuzione nello stesso lasso di tempo.
  • Durabilità (o persistenza): significa che una volta che la transazione è stata marcata come completata, i cambiamenti che essa ha apportato alla base dati non dovranno più essere persi, salvandoli quindi su supporto non volatile. Tali modifiche ai dati devono essere scritti in modo che ne venga garantita la leggibilità anche in caso di guasto del sistema.

Questo paradigma risale al 1970, formalizzato parzialmente (ACD, l’isolamento giunse successivamente) in uno storico documento del 1981 intitolato “The Transaction Concept: Virtues and Limitations” da Jim Grey e divenendo maturo nel 1983 in un documento intitolato “Principles of Transaction-Oriented Database Recovery” scritto da Andreas Reuter and Theo Härder.

I database relazionali ad uso OLTP- citiamo ad esempio i motori di database relazionale prodotti da Oracle e Microsoft – sono stati progettati mettendo quindi al centro affidabilità e coerenza dei dati gestiti, secondo questo paradigma.

Ma, come detto prima, questo paradigma attualmente non è l’unico ad avere rilevanza e considerazione.

A partire dalla metà degli anni 90, la crescente diffusione delle infrastruttura che rendono possibile il calcolo distribuito e l’avvento di un modello di database non strutturato hanno portato ai “database post-relazionale”.

Questo approccio diversamente strutturato ai dati richiede un’alternativa ad ACID e l’alternativa è il modello BASE.

Nel 2000, Eric Brewer – scienziato statunitense famoso per il “teorema CAP” che poi sarà utile introdurre – fece entrare l’acronimo BASE nell’uso comune utilizzandolo durante la propria presentazione al convegno della associazione ACM (Association for Computing Machinery) con un intervento dal titolo “Towards Robust Distributed Systems”.

Il cuore del Teorema CAP coinvolge i concetti di consistenza, disponibilità e tolleranza di partizione, che sono ovvie caratteristiche desiderabili da parte di un sistema, dalla sua progettazione alla sua implementazione.

Afferma che è impossibile, per un sistema informatico di calcolo distribuito fornire simultaneamente, tutte e tre le seguenti caratteristiche:

  • Coerenza: tutti i nodi del sistema vedono gli stessi dati nello stesso istante.
  • Disponibilità: garanzia che ogni richiesta riceva una risposta su ciò che sia riuscito o fallito.
  • Tolleranza di partizione: garanzia che il sistema continui a funzionare nonostante arbitrarie perdite di messaggi, di visibilità tra nodi.

Secondo il teorema, un sistema distribuito è in grado di soddisfare al massimo due di queste caratteristiche allo stesso tempo, ma non tutte e tre contemporaneamente.

Ma perché sto introducendo questo concetto dal teorema CAP? Perché esso aiuta a capire i fondamenti teorici alla base della distinzione tra ACID e BASE, in quanto esso implica, in altre parole, che un generico sistema distribuito ha tre possibilità di materializzarsi:

  • Sistemi che utilizzano tecnologie tradizionali relazionali – gli OLTP che possiamo definire classici – normalmente non sono tolleranti alla rottura di partizione. In pratica: se una componente di questi sistemi tradizionali non è in linea, l’intero sistema non è in linea.
  • Sistemi che garantiscono tolleranza di partizione e disponibilità non possono garantire la coerenza in lettura, in quanto gli aggiornamenti del valore del dato – che per definizione è il distruttore della coerenza – possono essere effettuate su entrambi i lati della partizione. Si vedano ad esempio: Dynamo, CouchDB (basati su chiave-valore) e Cassandra (basato su colonna). A tali sistemi, per approfondimento, dedicheremo successivi post.
  • Sistemi che garantiscono tolleranza di partizione e coerenza non possono garantire la disponibilità perché il sistema che gestisce questa base dati restituirebbe un errore fino a quando lo stato di anomalo partizionamento della propria integrità sarà risolto.

Il paradigma BASE è adeguato per applicazioni di tipo DSO in quanto essi non hanno come scopo quello di generare transazioni.

Il modello BASE consiste in queste 3 caratteristiche:

  • Basically Available – Fondamentalmente Disponibile: il sistema deve garantire la disponibilità dei dati, come specificato dal Teorema CAP – quindi ci sarà una risposta a qualsiasi richiesta. L’isolamento qui non è contemplato. Ma la risposta potrebbe ancora essere un “fallimento”, una impossibilità a rispondere.
  • Soft State – Stato Soft: lo stato del sistema può ambiare nel tempo, anche in periodi di tempo senza input ci possono essere cambiamenti in corso a causa, in questo modo lo stato del sistema è sempre “soft”. La consistenza dei dati diventa un problema da risolvere da parte dello sviluppatore e non deve essere gestita dal database.
  • Eventually Consistent – Eventuale Coerenza: quando nuovi dati vengono aggiunti al sistema essi si propagheranno gradatamente, un nodo alla volta, fino a far diventare consistente l’intero sistema

Si può dire che il modello BASE non è adatto per ogni situazione, ma è certamente un’alternativa flessibile al modello ACID per quelle architetture, situazioni e database che non richiedono il rispetto rigoroso di un modello relazionale.

Ora che alcuni aspetti teorici ritengo che siano stati affrontati, nei prossimi post di questa serie, ci concentreremo sulla categoria di database detti NOSQL dei quali – ricordiamo subito – la parte “NO” dell’acronimo non indica la negazione dei concetti del linguaggio SQL ma la relativa evoluzione secondo il significato: “Not Only SQL”, affermando che esistono casi d’uso in cui il modello tradizione relazionale è vincolante, una forzatura, ma che in altri casi tale modello è ancora la soluzione ottimale.

Dove ci sono alternative, dove c’è ingegneria e scelta, di solito c’è anche spazio per l’innovazione.

E dove c’è evoluzione – almeno nel campo del trattamento dati – io cerco di esserci.

Daniele Vanoncini

Annunci
Questa voce è stata pubblicata in divulgazione IT, lavoro e contrassegnata con , , , , , , , , , , , , , , , , , . Contrassegna il permalink.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...