SAV koncepció

3.1 A SAV megjelenése

Az ACID rövidítés először 1983-ban jelent meg Theo Haerder és Andreas Reuter cikkében. A szöveg egyszerűsítése és meggyőzőbbé tétele érdekében lefordítom a cikk egy töredékét (enyhe csökkentésekkel). Ez a részlet olyan banki tranzakció példáját használja, amelyben a pénz egyik számláról a másikra kerül át.

A tranzakció fogalma, amely a példában magában foglalja az adatbázissal való összes interakciót $BEGIN_TRANSACTIONés között $COMMIT_TRANSACTION, megköveteli, hogy minden műveletet oszthatatlanul hajtsanak végre: vagy minden művelet megfelelően tükröződik az adatbázis állapotában, vagy nem történik semmi. Ha a felhasználó elérése előtt bármikor $COMMIT_TRANSACTIONbeír egy utasítást, ERRORamely tartalmazza $RESTORE_TRANSACTIONa -t, akkor a változások nem jelennek meg az adatbázisban.

Az oszthatatlanság eléréséhez egy tranzakciónak a következő négy tulajdonsággal kell rendelkeznie:

Atomosság (Atomicitás). A tranzakciónak a fent leírt mindent vagy semmit típusúnak kell lennie, és bármi történjen is, a felhasználónak tudnia kell, hogy a tranzakció milyen állapotban van.

Konzisztencia (Consistency). Az a tranzakció, amely eléri a tranzakció normál végét (EOT), és ezáltal véglegesíti az eredményeit, megőrzi az adatbázis konzisztenciáját. Más szóval, minden sikeres tranzakció értelemszerűen csak érvényes eredményeket köt. Ez a feltétel szükséges a negyedik tulajdonság - a tartósság - támogatásához.

Izoláció (Isolation). A tranzakción belüli eseményeket el kell rejteni a többi, egyidejűleg végrehajtott tranzakció elől. Ha ez a feltétel nem teljesülne, akkor a fent említett okok miatt a tranzakció nem térhet vissza a kezdetéhez. Az izoláció eléréséhez szinkronizálásnak nevezett módszereket használnak ...

Tartósság (Durability). Miután egy tranzakció befejeződött, és eredményeit az adatbázisba helyezte, a rendszernek biztosítania kell, hogy ezek az eredmények túléljenek minden későbbi meghibásodást. Mivel nincs tranzakciókészletekre kiterjedő ellenőrzési hatókör, az adatbázis-kezelő rendszernek (DBMS) nincs ellenőrzése a tranzakciók határain túl.

Ezért a felhasználó számára garantálni kell, hogy ha a rendszer értesíti, hogy valami történt, akkor ez a „valami” valóban megtörtént. Mivel értelemszerűen bármely (sikeresen befejezett - S.K.) tranzakció helyes, az elkerülhetetlenül megjelenő hibás tranzakciók (azaz hibás adatokat tartalmazó tranzakciók) eredményeit csak a megfelelő „ellentranzakció” (ellentranzakció) tudja kiküszöbölni.

3.2 A tranzakciók megjelenése

Ez a négy tulajdonság – Atomicity, Consistency, Isolation és Durability (ACID) – írja le a tranzakciós paradigma azon alapvető jellemzőit, amelyek az adatbázis-rendszer tervezésének számos aspektusát érintik. Ezért úgy gondoljuk, hogy bármely rendszer azon képessége, hogy támogassa a tranzakciókat, a rendszer minőségének próbaköve (ACID teszt).

Egy egyszerű PL/1-SQL program, amely pénzt utal át egyik számláról a másikra.

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

Példát adtam erre a kódra, hogy emlékeztessem Önt arra, hogy valójában az ACID tulajdonságok egyrészt minden olyan DBMS követelményének tekinthetők, amely azt állítja, hogy támogatja a tranzakciókat, másrészt pedig egy tranzakció definíciójának tekinthető adatbázis rendszer . Ez a meghatározás teljes mértékben összhangban van a világi gyakorlattal. Nehéz elképzelni például, hogy egy banki tranzakciót végrehajtó ügyfél (akár élő emberszámláló segítségével, akár internetes bankolás segítségével) ne várja el a banktól, hogy az ACID minden tulajdonságát kielégítse. Az a bank, amely nem támogatja az ACID tulajdonságokat a tranzakcióihoz, a legjobb esetben is ügyfeleket veszít, rosszabb esetben pedig csődbe megy.

3.3 ACID csatlakozás

Nagyon fontos, hogy az ACID tulajdonságok elválaszthatatlanok legyenek, bármelyikük elvetése értelmetlenné teszi a fennmaradó kombinációt. Különösen, ha elvetjük a konzisztencia tulajdonságot (abban az értelemben, ahogyan a fenti idézetben használtuk), akkor elveszítjük a tranzakció helyességének kritériumát. Az adatbázisrendszer nem tudja majd érdemben eldönteni, hogy a tranzakciók engedélyezettek-e vagy sem, és az adatbázis aktuális állapotában végrehajtott műveletek helyességének minden ellenőrzését alkalmazáskódban kell végrehajtani.

Meg kell értenie, hogy ebben az esetben logikai következetességről beszélünk. A bank ügyfelének szüksége van arra, hogy a bank az általa kialakított és az ügyfelek által ismert szabályok szerint működjön, hogy ne lehessen e szabályokat sértő tranzakciót végrehajtani, így ugyanazon ügyfél következő tranzakciója egy e szabályokkal összhangban megállapodott környezet.

A webáruház ügyfelének szüksége van arra, hogy az általa megrendelt és kifizetett árut időben (a kialakított és az ügyfél által ismert szabályok szerint) kézbesítsék. Ellenkező esetben nem fog megbízni ebben az üzletben. Ugyanakkor sem a bank ügyfelét, sem az internetes áruház ügyfelét nem érdekli a vállalkozás belső konyhája, hogy milyen belső lépéseket tesznek a tranzakció lebonyolításához. Az ügyfelet nem érdekli, hogyan tartják fenn ennek a vállalkozásnak a fizikai konzisztenciáját, hogyan hajtják végre a műveleteket a fizikai rétegen.

Ha a DBMS gondoskodik a tranzakciók (és az adatbázis) logikai konzisztenciájának megőrzéséről, akkor az alkalmazások egyszerűbbé, érthetőbbé és megbízhatóbbá válnak. Az alkalmazási terület (bank, üzlet, raktár stb.) minden logikája a tranzakciókra és az adatok érvényes állapotára vonatkozóan az adatbázis rendszerbe kerül. A rendszer követelményei pedig nagyon egyszerűek: ACID-tranzakciók támogatása, figyelembe véve az alkalmazás által az adatbázisban biztosított konzisztencia-szabályokat. Az ACID-tranzakciók elutasítása szerintem mértéktelen nehézségeket okoz az alkalmazásfejlesztőknek, akiknek akár tetszik, akár nem, maguknak kell valami hasonlót megvalósítaniuk, hogy kielégíthessék vásárlóik természetes igényeit.

És még egyszer megjegyzem, hogy az ACID tulajdonságok valójában meghatározzák a tranzakció fogalmát. Véleményem szerint ahhoz, hogy legalább egy olyan tranzakciós adatkezelő rendszerről lehessen beszélni, amelyben a tranzakciókonzisztencia tulajdonsága nem támogatott, feltétlenül szükséges meghatározni, hogy ebben az esetben mit kell érteni a tranzakció fogalmán.

Sajnos manapság sok esetben (főleg a NoSQL-irányra jellemző ez) az OLTP-alkalmazások támogatásáról beszélnek az emberek anélkül, hogy egyáltalán meghatároznák, milyen tranzakciókra gondolnak. Ezért ebben a cikkben az ACID tranzakció kombinációt fogom használni a valós tranzakciókra, és a minősíthetetlen tranzakció kifejezést informális értelemben fogom használni, különböző kontextusokban eltérően.

Foglalkozzunk most a KAP „tételével”, és próbáljuk meg kitalálni, mit jelent Brewer értelmében a következetesség.