3.1 Emergenza di ACIDO
L'abbreviazione ACID è apparsa per la prima volta nel 1983 in un articolo di Theo Haerder e Andreas Reuter. Per semplificare il testo e renderlo più convincente, darò una traduzione di un frammento di questo articolo (con leggere riduzioni). Questo frammento utilizza un esempio di transazione bancaria in cui il denaro viene trasferito da un conto a un altro.
Il concetto di transazione, che nell'esempio include tutte le interazioni con il database tra $BEGIN_TRANSACTIONe $COMMIT_TRANSACTION, richiede che tutte le azioni vengano eseguite indivisibilmente: o tutte le azioni si riflettono correttamente nello stato del database, oppure non accade nulla. Se in qualsiasi momento prima di raggiungere $COMMIT_TRANSACTIONl'utente immette un'istruzione ERRORcontenente $RESTORE_TRANSACTION, nessuna modifica viene riflessa nel database.
Per ottenere questa indivisibilità, una transazione deve avere le seguenti quattro proprietà:
Atomicità (atomicità). La transazione deve essere del tipo tutto o niente descritto sopra e, qualunque cosa accada, l'utente deve sapere in che stato si trova la transazione.
Coerenza (coerenza). Una transazione che raggiunge la normale fine della transazione (EOT) e quindi esegue il commit dei risultati mantiene la coerenza del database. In altre parole, ogni transazione riuscita, per definizione, impegna solo risultati validi. Questa condizione è necessaria per supportare la quarta proprietà: la durabilità.
Isolamento (isolamento). Gli eventi che si verificano all'interno di una transazione devono essere nascosti da altre transazioni in esecuzione contemporaneamente. Se questa condizione non fosse soddisfatta, allora per i motivi sopra menzionati, la transazione sarebbe impossibile tornare al suo inizio. Per ottenere l'isolamento, vengono utilizzati metodi chiamati sincronizzazione ...
Durata (durata). Una volta che una transazione è stata completata e i suoi risultati sono stati depositati nel database, il sistema deve garantire che tali risultati sopravvivano a eventuali errori successivi. Poiché non esiste un ambito di controllo che si estende a insiemi di transazioni, il sistema di gestione del database (DBMS) non ha alcun controllo oltre i confini delle transazioni.
Pertanto, all'utente deve essere garantito che se il sistema lo informa che è successo qualcosa, allora questo "qualcosa" è realmente accaduto. Poiché, per definizione, qualsiasi transazione (completata con successo - S.K.) è corretta, i risultati dell'inevitabile apparizione di transazioni errate (ovvero transazioni contenenti dati errati) possono essere eliminati solo dalla corrispondente transazione "contro" (controtransazione).
3.2 L'emergere delle transazioni
Queste quattro proprietà, Atomicità, Consistenza, Isolamento e Durabilità (ACID), descrivono le caratteristiche fondamentali del paradigma transazionale che influiscono su molti aspetti della progettazione del sistema di database. Pertanto, riteniamo che la capacità di qualsiasi sistema di supportare le transazioni sia la pietra di paragone (test ACID) della qualità di questo sistema.
Un semplice programma PL/1-SQL che trasferisce fondi da un conto all'altro.
FUNDS_TRANSFER. PROCEDURE,
$BEGIN_TRANSACTION;
ON ERROR DO; /* in case of error */
$RESTORE_TRANSACTION, /* undo all work */
GET INPUT MESSAGE; /* reacquire input */
PUT MESSAGE ('TRANSFER FAILED'); /* report failure */
GO TO COMMIT;
END;
GET INPUT MESSAGE; /* get and parse input */
EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
AMOUNT FROM MESSAGE,
$UPDATE ACCOUNTS /* do debit */
SET BALANCE ffi BALANCE - AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
$UPDATE ACCOUNTS /* do credit */
SET BALANCE = BALANCE + AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
$INSERT INTO HISTORY /* keep audit trail */
<DATE, MESSAGE>;
PUT MESSAGE ('TRANSFER DONE'); /* report success */
COMMIT: /* commit updates */
$COMMIT_TRANSACTION;
END; /* end of program */Ho fornito un esempio di questo codice per ricordare che, infatti, le proprietà ACID, da un lato, possono essere considerate come requisiti per qualsiasi DBMS che pretenda di supportare le transazioni e, dall'altro, come la definizione di una transazione in un sistema di banche dati . Questa definizione è pienamente coerente con la pratica mondana. È difficile immaginare, ad esempio, che un cliente che esegue una transazione bancaria (con l'assistenza di un cassiere umano dal vivo o utilizzando Internet banking) non si aspetti che la banca soddisfi tutte le proprietà di ACID. Una banca che non supporta le proprietà ACID per le sue transazioni perderà, nel migliore dei casi, clienti e, nel peggiore dei casi, fallirà.
3.3 Connettività ACID
È molto importante che le proprietà ACID siano inseparabili, scartarne qualcuna rende priva di significato la combinazione rimanente. In particolare, se scartiamo la proprietà di consistenza (nel senso in cui è stata usata nella citazione sopra), allora perderemo il criterio per la correttezza di una transazione. Il sistema di database non sarà in grado di decidere in modo significativo se le transazioni possono o meno essere impegnate e tutti i controlli per la correttezza delle operazioni eseguite nello stato corrente del database dovranno essere eseguiti nel codice dell'applicazione.
Devi capire che in questo caso stiamo parlando di coerenza logica. Il cliente della banca ha bisogno che la banca operi secondo le regole da lui stabilite e note ai clienti, in modo che sia impossibile eseguire qualsiasi transazione che violi queste regole, in modo che la successiva transazione dello stesso cliente venga eseguita in modo ambiente concordato in conformità con queste regole.
Il cliente del negozio online ha bisogno che la merce da lui ordinata e pagata gli venga consegnata tempestivamente (secondo le regole stabilite e note al cliente). Altrimenti, non si fiderà di questo negozio. Allo stesso tempo, né il cliente della banca né il cliente del negozio Internet si preoccupano della cucina interna dell'impresa, quali azioni interne vengono intraprese per completare la sua transazione. Al cliente non interessa come viene mantenuta la coerenza fisica di questa impresa, come vengono eseguite le operazioni a livello fisico.
Se il DBMS si occupa di mantenere la coerenza logica delle transazioni (e del database), allora le applicazioni diventano più semplici, più comprensibili e più affidabili. Tutta la logica dell'area applicativa (banca, negozio, magazzino, ecc.) relativa alle transazioni e allo stato di validità dei dati entra nel sistema di database. E i requisiti per questo sistema sono molto semplici: supporto per le transazioni ACID, tenendo conto delle regole di coerenza fornite nel database dall'applicazione. Dal mio punto di vista, il rifiuto delle transazioni ACID crea difficoltà smodate per gli sviluppatori di applicazioni, che, piaccia o no, dovranno implementare loro stessi qualcosa di simile per soddisfare le esigenze naturali dei loro clienti.
E ancora una volta noto che le proprietà ACID, infatti, definiscono il concetto di transazione. A mio parere, per avere almeno qualche possibilità di parlare di un sistema transazionale di gestione dei dati in cui la proprietà della consistenza della transazione non è supportata, è assolutamente necessario definire cosa si intende con il termine transazione in questo caso.
Sfortunatamente, oggi in molti casi (in particolare, questo è caratteristico della direzione NoSQL), si parla di supportare applicazioni OLTP senza specificare affatto che tipo di transazioni intendono. Pertanto, in questo articolo, utilizzerò la combinazione transazione ACID per riferirmi a transazioni reali e il termine transazione non qualificato verrà utilizzato in senso informale, diverso nei diversi contesti.
Occupiamoci ora del "teorema" di CAP e cerchiamo di capire cosa significhi consistenza nel senso di Brewer.