SYRA koncept

3.1 Uppkomst av SYRA

Förkortningen ACID dök upp första gången 1983 i en artikel av Theo Haerder och Andreas Reuter. För att förenkla texten och göra den mer övertygande kommer jag att ge en översättning av ett fragment av den här artikeln (med lätta förminskningar). Det här utdraget använder ett exempel på en banktransaktion där pengar överförs från ett konto till ett annat.

Konceptet med en transaktion, som i exemplet inkluderar all interaktion med databasen mellan $BEGIN_TRANSACTIONoch $COMMIT_TRANSACTION, kräver att alla åtgärder utförs odelbart: antingen återspeglas alla åtgärder korrekt i databasens tillstånd eller så händer ingenting. $COMMIT_TRANSACTIONOm användaren vid någon tidpunkt innan han når ett uttalande ERRORsom innehåller $RESTORE_TRANSACTION, återspeglas inga ändringar i databasen.

För att uppnå denna odelbarhet måste en transaktion ha följande fyra egenskaper:

Atomicitet (Atomicitet). Transaktionen måste vara av allt-eller-inget-typen som beskrivs ovan, och oavsett vad som händer måste användaren veta vilket tillstånd transaktionen är i.

Konsistens (Konsistens). En transaktion som når sitt normala slut på transaktionen (EOT) och därigenom förbinder sina resultat upprätthåller databaskonsistens. Med andra ord, varje framgångsrik transaktion ger per definition endast giltiga resultat. Detta villkor är nödvändigt för att stödja den fjärde egenskapen - hållbarhet.

Isolation (Isolation). Händelser som inträffar inom en transaktion måste döljas från andra transaktioner som utförs samtidigt. Om detta villkor inte var uppfyllt, skulle transaktionen av de skäl som nämnts ovan vara omöjlig att återgå till dess början. För att uppnå isolering används metoder som kallas synkronisering ...

Durability (Durability). När en transaktion har slutförts och skickat sina resultat till databasen måste systemet säkerställa att dessa resultat överlever eventuella efterföljande misslyckanden. Eftersom det inte finns någon kontrollomfattning som sträcker sig över uppsättningar av transaktioner, har databashanteringssystemet (DBMS) ingen kontroll utanför transaktionsgränserna.

Därför måste användaren garanteras att om systemet informerar honom om att något har hänt, så har detta "något" verkligen hänt. Eftersom varje (framgångsrikt genomförd - S.K.) transaktion per definition är korrekt, kan resultaten av oundvikligen uppträdande felaktiga transaktioner (d.v.s. transaktioner som innehåller felaktiga data) endast elimineras av motsvarande "mottransaktion" (mottransaktion).

3.2 Uppkomsten av transaktioner

Dessa fyra egenskaper – Atomicity, Consistency, Isolation och Durability (ACID) – beskriver kärnfunktionerna i transaktionsparadigmet som påverkar många aspekter av databassystemdesign. Därför tror vi att förmågan hos vilket system som helst att stödja transaktioner är provstenen (ACID-test) för kvaliteten på detta system.

Ett enkelt PL/1-SQL-program som överför pengar från ett konto till ett annat.

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

Jag gav ett exempel på denna kod för att påminna dig om att faktiskt ACID-egenskaper å ena sidan kan betraktas som krav för alla DBMS som påstår sig stödja transaktioner, och å andra sidan som definitionen av en transaktion i ett databassystem . Denna definition är helt förenlig med världslig praxis. Det är till exempel svårt att föreställa sig att en kund som utför en banktransaktion (oavsett om det är med hjälp av en direktsänd rösträknare eller använder internetbank) inte förväntar sig att banken ska tillfredsställa ACIDs alla egenskaper. En bank som inte stöder ACID-fastigheter för sina transaktioner kommer i bästa fall att förlora kunder och i värsta fall gå i konkurs.

3.3 ACID-anslutning

Det är mycket viktigt att ACID-egenskaperna är oskiljaktiga, att kassera någon av dem gör den återstående kombinationen meningslös. I synnerhet om vi kasserar konsistensegenskapen (i den mening som den användes i ovanstående citat), kommer vi att förlora kriteriet för en transaktions korrekthet. Databassystemet kommer inte att kunna avgöra på något meningsfullt sätt om transaktioner är tillåtna eller inte ska utföras, och alla kontroller för korrektheten av operationer som utförs i databasens nuvarande tillstånd kommer att behöva utföras i applikationskod.

Du måste förstå att vi i det här fallet talar om logisk konsekvens. Bankens klient behöver banken för att arbeta enligt de regler som fastställts av honom och som är kända för kunderna, så att det är omöjligt att utföra någon transaktion som bryter mot dessa regler, så att nästa transaktion för samma kund utförs i en miljö som överenskommits i enlighet med dessa regler.

Kunden till nätbutiken behöver att varorna som beställts och betalats av honom levereras till honom i tid (i enlighet med de regler som är etablerade och kända för kunden). Annars kommer han inte att lita på den här butiken. Samtidigt bryr sig varken bankens klient eller internetbutikens klient om företagets interna kök, vilka interna åtgärder som vidtas för att slutföra transaktionen. Kunden bryr sig inte om hur den fysiska konsistensen i detta företag upprätthålls, hur verksamheten utförs på den fysiska nivån.

Om DBMS tar hand om att upprätthålla den logiska konsistensen av transaktioner (och databasen) blir applikationerna enklare, mer begripliga och mer tillförlitliga. All logik i applikationsområdet (bank, butik, lager, etc.) angående transaktioner och datas giltiga tillstånd går in i databassystemet. Och kraven för detta system är mycket enkla: stöd för ACID-transaktioner, med hänsyn till konsistensreglerna som tillhandahålls av applikationen i databasen. Ur min synvinkel skapar avvisningen av ACID-transaktioner omåttliga svårigheter för applikationsutvecklare, som, vare sig du vill det eller inte, kommer att behöva implementera något liknande själva för att tillfredsställa de naturliga behoven hos sina kunder.

Och återigen noterar jag att ACID-egenskaperna faktiskt definierar begreppet en transaktion. För att åtminstone ha en viss möjlighet att tala om ett transaktionsdatahanteringssystem där egenskapen transaktionskonsistens inte stöds, är det enligt min mening absolut nödvändigt att definiera vad som menas med termen transaktion i detta fall.

Tyvärr talar man idag i många fall (särskilt detta är karakteristiskt för NoSQL-riktningen) om att stödja OLTP-applikationer utan att alls specificera vilken typ av transaktioner de menar. Därför kommer jag i den här artikeln att använda kombinationen ACID-transaktion för att referera till verkliga transaktioner, och den okvalificerade termen transaktion kommer att användas i en informell mening, olika i olika sammanhang.

Låt oss nu ta itu med "satsen" för CAP och försöka lista ut vad konsekvens betyder i Brewers mening.