Come vi muovete entro il dilemma fra ACID e BASE? Chiariamo subito che non siete capitati in un sito di chimica e neppure di cultura lisergica. Qui si parla di database. ACID e BASE sono due acronimi, ben noti a chi sviluppa software. Essi si riferiscono alla qualità delle transazioni di una base dati. Ce ne occupiamo perché, fra questi due paradigmi è in atto un sommovimento storico nell’ambito della computer science. Ma procediamo con ordine
Oggigiorno abbiamo una moltitudine di sistemi a supporto delle decisioni basati sui dati (DSO, Decision Support Object o DSS, Decision Support System). Tali dati provengono in genere da altri sistemi, quelli che – riga dopo riga, transazione per transazione – li generano affinché siano analizzati in seguito. Questi sistemi detti 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.
Insomma: gli OLTP generano dati, i DSO consultano in modo massivo dati generati dagli OLTP.
Ora concentriamoci sull’uso del dato, sul modo in cui viene fruito (non generato), un modo sostanzialmente differente tra un DSO e un OLTP relazionale. Le differenze sono tali che alla base troviamo due diversi paradigmi. 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.
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 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 totale, completa oppure nulla o 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 articolo del 1981 intitolato The Transaction Concept: Virtues and Limitations da Jim Grey e divenendo maturo nel 1983 in un secondo documento intitolato Principles of Transaction-Oriented Database Recovery, scritto da Andreas Reuter e 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 infrastrutture che rendono possibile il calcolo distribuito e l’avvento di un modello di database non strutturato hanno portato ai “database post-relazionali”. 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. Brewer afferma che è impossibile, per un sistema informatico di calcolo distribuito, fornire simultaneamente tutte e tre le seguenti caratteristiche:
1) Coerenza: tutti i nodi del sistema vedono gli stessi dati nello stesso istante.
2) Disponibilità: garanzia che ogni richiesta riceva una risposta su ciò che sia riuscito o fallito.
3) 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é introduciamo il concetto dal teorema CAP? Perché esso aiuta a capire i fondamenti teorici alla base della distinzione tra ACID e BASE, in quanto implica che un generico sistema distribuito ha tre possibilità di materializzarsi:
A) 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.
B) 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 effettuati 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.
C) 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 tre caratteristiche:
1) 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.
2) 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.
3) 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.
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 – noi ci siamo.
Foto: tec_estromberg
