Conceptul ACID

3.1 Apariția ACID

Abrevierea ACID a apărut pentru prima dată în 1983 într-un articol al lui Theo Haerder și Andreas Reuter. Pentru a simplifica textul și a-l face mai convingător, voi oferi o traducere a unui fragment din acest articol (cu mici reduceri). Acest fragment folosește un exemplu de tranzacție bancară în care banii sunt transferați dintr-un cont în altul.

Conceptul de tranzacție, care în exemplu include toate interacțiunile cu baza de date între $BEGIN_TRANSACTIONși $COMMIT_TRANSACTION, necesită ca toate acțiunile să fie efectuate indivizibil: fie toate acțiunile sunt reflectate corespunzător în starea bazei de date, fie nu se întâmplă nimic. Dacă în orice moment înainte de a ajunge $COMMIT_TRANSACTIONutilizatorul introduce o declarație ERRORcare conține $RESTORE_TRANSACTION, atunci nicio modificare nu se reflectă în baza de date.

Pentru a obține această indivizibilitate, o tranzacție trebuie să aibă următoarele patru proprietăți:

Atomicity (Atomicity). Tranzacția trebuie să fie de tipul totul sau nimic descris mai sus și indiferent de ce se întâmplă, utilizatorul trebuie să știe în ce stare se află tranzacția.

Consistency (Consistency). O tranzacție care ajunge la sfârșitul normal al tranzacției (EOT) și, prin urmare, își angajează rezultatele, menține consistența bazei de date. Cu alte cuvinte, fiecare tranzacție de succes, prin definiție, angajează doar rezultate valide. Această condiție este necesară pentru a susține a patra proprietate - durabilitatea.

Izolare (Izolare). Evenimentele care au loc în cadrul unei tranzacții trebuie să fie ascunse de alte tranzacții care se execută concomitent. Dacă această condiție nu ar fi îndeplinită, atunci din motivele menționate mai sus, tranzacția ar fi imposibil de revenit la începutul ei. Pentru a realiza izolarea, se folosesc metode numite sincronizare...

Durabilitate (Durability). Odată ce o tranzacție a fost finalizată și a trimis rezultatele în baza de date, sistemul trebuie să se asigure că acele rezultate supraviețuiesc oricăror eșecuri ulterioare. Deoarece nu există un domeniu de control care să acopere seturi de tranzacții, sistemul de management al bazei de date (DBMS) nu are control dincolo de limitele tranzacțiilor.

Prin urmare, utilizatorului trebuie să i se garanteze că, dacă sistemul îl informează că s-a întâmplat ceva, atunci acest „ceva” s-a întâmplat cu adevărat. Deoarece, prin definiție, orice tranzacție (finalizată cu succes - S.K.) este corectă, rezultatele tranzacțiilor care apar inevitabil incorecte (adică tranzacții care conțin date eronate) pot fi eliminate doar prin tranzacția „contor” corespunzătoare (contratranzacție).

3.2 Apariția tranzacțiilor

Aceste patru proprietăți - Atomicity, Consistency, Isolation, and Durability (ACID) - descriu caracteristicile de bază ale paradigmei tranzacționale care afectează multe aspecte ale proiectării sistemului de baze de date. Prin urmare, credem că capacitatea oricărui sistem de a suporta tranzacții este piatra de încercare (testul ACID) a calității acestui sistem.

Un program simplu PL/1-SQL care transferă fonduri dintr-un cont în altul.

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 */

Am oferit un exemplu al acestui cod pentru a vă aminti că, de fapt, proprietățile ACID, pe de o parte, pot fi considerate cerințe pentru orice SGBD care pretinde că suportă tranzacții și, pe de altă parte, ca definiție a unei tranzacții în un sistem de baze de date . Această definiție este pe deplin în concordanță cu practica lumească. Este greu de imaginat, de exemplu, că un client care efectuează o tranzacție bancară (fie cu asistența unui casier uman în direct sau folosind Internet banking) nu se așteaptă ca banca să satisfacă toate proprietățile ACID. O bancă care nu acceptă proprietățile ACID pentru tranzacțiile sale va pierde, în cel mai bun caz, clienți și, în cel mai rău caz, va da faliment.

3.3 Conectivitate ACID

Este foarte important ca proprietățile ACIDE să fie inseparabile, aruncarea oricăruia dintre ele face ca combinația rămasă să nu aibă sens. În special, dacă renunțăm la proprietatea de consistență (în sensul în care a fost folosită în citatul de mai sus), atunci vom pierde criteriul de corectitudine a unei tranzacții. Sistemul de baze de date nu va putea decide în niciun mod semnificativ dacă tranzacțiile sunt permise sau nu să fie comise, iar toate verificările pentru corectitudinea operațiunilor efectuate în starea curentă a bazei de date vor trebui efectuate în codul aplicației.

Trebuie să înțelegeți că în acest caz vorbim de consistență logică. Clientul băncii are nevoie ca banca să funcționeze conform regulilor stabilite de el și cunoscute clienților, astfel încât să fie imposibilă efectuarea vreunei tranzacții care încalcă aceste reguli, astfel încât următoarea tranzacție a aceluiași client să fie executată într-un mediu agreat în conformitate cu aceste reguli.

Clientul magazinului online are nevoie ca bunurile comandate si platite de el sa i se livreze in timp util (in conformitate cu regulile stabilite si cunoscute de client). Altfel, nu va avea încredere în acest magazin. În același timp, nici clientului băncii și nici clientului magazinului pe Internet nu îi pasă de bucătăria internă a întreprinderii, de ce acțiuni interne se întreprind pentru a finaliza tranzacția acesteia. Clientului nu îi pasă cum se menține consistența fizică a acestei întreprinderi, cum se desfășoară operațiunile la nivel fizic.

Dacă SGBD se ocupă de menținerea consistenței logice a tranzacțiilor (și a bazei de date), atunci aplicațiile devin mai simple, mai ușor de înțeles și mai fiabile. Toată logica zonei de aplicație (bancă, magazin, depozit etc.) privind tranzacțiile și starea valabilă a datelor intră în sistemul de baze de date. Iar cerințele pentru acest sistem sunt foarte simple: suport pentru tranzacțiile ACID, ținând cont de regulile de consistență furnizate în baza de date de aplicație. Din punctul meu de vedere, respingerea tranzacțiilor ACID creează dificultăți nemoderate dezvoltatorilor de aplicații, care, fie că vă place sau nu, vor trebui să implementeze ei înșiși ceva asemănător pentru a satisface nevoile firești ale clienților lor.

Și încă o dată observ că proprietățile ACID, de fapt, definesc conceptul de tranzacție. În opinia mea, pentru a avea măcar o oarecare posibilitate de a vorbi despre un sistem de management al datelor tranzacționale în care nu este susținută proprietatea consistenței tranzacției, este absolut necesar să se definească ce se înțelege prin termenul de tranzacție în acest caz.

Din păcate, astăzi în multe cazuri (în special, aceasta este caracteristică direcției NoSQL), oamenii vorbesc despre suportarea aplicațiilor OLTP fără a specifica deloc ce fel de tranzacții înseamnă. Prin urmare, în acest articol, voi folosi combinația ACID tranzacție pentru a face referire la tranzacții reale, iar termenul necalificat tranzacție va fi folosit într-un sens informal, diferit în contexte diferite.

Să ne ocupăm acum de „teorema” CAP și să încercăm să ne dăm seama ce înseamnă consistența în sensul lui Brewer.