Discutiamo i modelli di consistenza ACID e BASE.
ACID
Il termine ACID sta per Atomicità, Consistenza, Isolamento e Durabilità. Le proprietà ACID sono utilizzate per mantenere l’integrità dei dati durante l’elaborazione delle transazioni.
Per mantenere la coerenza prima e dopo una transazione, i database relazionali seguono le proprietà ACID. Cerchiamo di capire questi termini:
Atomicità
Tutte le operazioni di una transazione hanno successo o ogni operazione viene annullata.
Consistenza
Al termine di una transazione, il database è in uno stato consistente.
Isolamento
Transazioni multiple non vanno in conflitto tra loro. L’accesso conflittuale ai dati è moderato dal database in modo che le transazioni sembrino eseguite in sequenza.
Durabilità
Una volta che la transazione è stata completata e le scritture e gli aggiornamenti sono stati scritti sul disco, l’aggiornamento rimarrà nel sistema anche se si verifica un guasto del sistema.
BASE
Con la crescente quantità di dati, la flessibilità sulla struttura di essi e i requisiti di alta disponibilità, anche l’approccio alla progettazione dei database è cambiato radicalmente. Per aumentare la capacità di scalare e allo stesso tempo di essere altamente disponibili, spostiamo la logica dal database a server separati. In questo modo, il database diventa più indipendente e si concentra sul processo effettivo di archiviazione dei dati.
Nel mondo dei database NoSQL, le transazioni ACID sono meno comuni, poiché alcuni database hanno allentato i requisiti di consistenza immediata per ottenere altri vantaggi, come la scalabilità e la flessibilità.
Le proprietà BASE sono molto meno rigide delle garanzie ACID, ma non esiste una corrispondenza diretta uno a uno tra i due modelli di consistenza. Cerchiamo di capire questi termini:
Basic Availability
Il database/datastore è prevalentemente disponibile per la maggior parte del tempo.
Soft-state
Lo stato del sistema può cambiare nel tempo, anche senza che vengano effettuate scritture. Ciò è dovuto al modello di coerenza eventuale.
Eventual consistency
I dati potrebbero non essere immediatamente coerenti, ma alla fine lo diventano (in un limitato lasso di tempo). Le letture nel sistema sono ancora possibili anche se potrebbero non dare la risposta corretta a causa dell’inconsistenza.
ACID vs BASE Trade-offs
Non esiste una risposta giusta per stabilire se la nostra applicazione ha bisogno di un modello di consistenza ACID o BASE. Entrambi i modelli sono stati progettati e cuesistono per soddisfare requisiti diversi. Nella scelta di un database/datastore dobbiamo tenere conto delle proprietà di entrambi i modelli e dei requisiti della nostra applicazione.
Data la scarsa consistenza di BASE, gli sviluppatori devono essere più informati e rigorosi sulla consistenza dei dati se scelgono un approccio BASE per la loro applicazione. È essenziale conoscere il comportamento del database scelto e lavorare all’interno di questi vincoli.
D’altra parte, pianificare un approccio BASE quando non necessario può rappresentare un grosso svantaggio rispetto alla semplicità delle transazioni ACID. Un database completamente ACID è perfetto per i casi d’uso in cui l’affidabilità e la coerenza dei dati sono essenziali, ad esempio come succede dei RDBMS come MySQL e PostgreSQL.
Piccolo easter-egg, l’acronimo BASE non è stato coniato in modo del tutto casuale, bensì per marcare l’esatta contrapposizione con il modello ACID come succede esattamente in chimica con le soluzioni acide e basiche, eravate già a conoscenza di questa curiosità? 😀