SYRE koncept

3.1 Fremkomst af SYRE

Forkortelsen ACID dukkede første gang op i 1983 i en artikel af Theo Haerder og Andreas Reuter. For at forenkle teksten og gøre den mere overbevisende vil jeg give en oversættelse af et fragment af denne artikel (med små reduktioner). Dette uddrag bruger et eksempel på en banktransaktion, hvor penge overføres fra en konto til en anden.

Konceptet med en transaktion, som i eksemplet omfatter alle interaktioner med databasen mellem $BEGIN_TRANSACTIONog $COMMIT_TRANSACTION, kræver, at alle handlinger udføres udeleligt: ​​enten afspejles alle handlinger korrekt i databasens tilstand, eller også sker der ikke noget. $COMMIT_TRANSACTIONHvis brugeren på et hvilket som helst tidspunkt, før den når frem, indtaster en erklæring ERROR, der indeholder $RESTORE_TRANSACTION, afspejles ingen ændringer i databasen.

For at opnå denne udelelighed skal en transaktion have følgende fire egenskaber:

Atomicitet (Atomicitet). Transaktionen skal være af alt-eller-intet-typen beskrevet ovenfor, og uanset hvad der sker, skal brugeren vide, hvilken tilstand transaktionen er i.

Konsistens (Konsistens). En transaktion, der når sin normale transaktionsslutning (EOT) og derved forpligter sine resultater, bevarer databasekonsistens. Med andre ord, hver succesfuld transaktion forpligter per definition kun gyldige resultater. Denne betingelse er nødvendig for at understøtte den fjerde egenskab - holdbarhed.

Isolation (Isolation). Hændelser, der opstår inden for en transaktion, skal skjules fra andre samtidig udførende transaktioner. Hvis denne betingelse ikke var opfyldt, ville transaktionen af ​​ovennævnte årsager være umulig at vende tilbage til sin begyndelse. For at opnå isolation bruges metoder kaldet synkronisering ...

Holdbarhed (Durability). Når en transaktion er gennemført og overført sine resultater til databasen, skal systemet sikre, at disse resultater overlever eventuelle efterfølgende fejl. Da der ikke er nogen kontrolomfang, der spænder over sæt af transaktioner, har databasestyringssystemet (DBMS) ingen kontrol ud over grænserne for transaktioner.

Derfor skal brugeren være garanteret, at hvis systemet informerer ham om, at der er sket noget, så er dette "noget" virkelig sket. Da enhver (succesfuld gennemført - S.K.) transaktion pr. definition er korrekt, kan resultaterne af uundgåeligt forekommende forkerte transaktioner (dvs. transaktioner indeholdende fejlagtige data) kun elimineres af den tilsvarende "modtransaktion" (modtransaktion).

3.2 Fremkomsten af ​​transaktioner

Disse fire egenskaber - Atomicitet, Konsistens, Isolation og Holdbarhed (ACID) - beskriver kerneegenskaberne i det transaktionelle paradigme, der påvirker mange aspekter af databasesystemdesign. Derfor mener vi, at ethvert systems evne til at understøtte transaktioner er prøvestenen (ACID-testen) for kvaliteten af ​​dette system.

Et simpelt PL/1-SQL-program, der overfører penge fra en konto til en anden.

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

Jeg gav et eksempel på denne kode for at minde dig om, at ACID-egenskaber faktisk på den ene side kan betragtes som krav til enhver DBMS, der hævder at understøtte transaktioner, og på den anden side som definitionen af ​​en transaktion i et databasesystem . Denne definition er fuldstændig i overensstemmelse med verdslig praksis. Det er f.eks. svært at forestille sig, at en kunde, der udfører en banktransaktion (uanset om det er med hjælp fra en menneskelig tæller eller ved hjælp af internetbank), ikke forventer, at banken opfylder alle ACIDs egenskaber. En bank, der ikke understøtter ACID-ejendomme til sine transaktioner, vil i bedste fald miste kunder og i værste fald gå konkurs.

3.3 ACID-forbindelse

Det er meget vigtigt, at ACID-egenskaberne er uadskillelige, at kassere nogen af ​​dem gør den resterende kombination meningsløs. Især hvis vi kasserer konsistensegenskaben (i den betydning, som den blev brugt i ovenstående citat), så mister vi kriteriet for rigtigheden af ​​en transaktion. Databasesystemet vil ikke være i stand til på nogen meningsfuld måde at afgøre, om transaktioner er tilladt eller ej, og alle kontroller for rigtigheden af ​​operationer udført i databasens aktuelle tilstand skal udføres i applikationskode.

Du skal forstå, at vi i dette tilfælde taler om logisk konsistens. Bankens klient har brug for, at banken arbejder i henhold til de regler, han har fastlagt og kendt af kunderne, således at det er umuligt at udføre en transaktion, der overtræder disse regler, således at den næste transaktion af samme kunde udføres i en miljø aftalt i overensstemmelse med disse regler.

Kunden af ​​onlinebutikken har brug for, at de varer, som er bestilt og betalt af ham, skal leveres til ham rettidigt (i overensstemmelse med de regler, der er etableret og kendt af kunden). Ellers vil han ikke stole på denne butik. Samtidig bekymrer hverken bankens klient eller internetbutikkens klient sig om virksomhedens interne køkken, hvilke interne handlinger der tages for at fuldføre transaktionen. Kunden er ligeglad med, hvordan den fysiske sammenhæng i denne virksomhed opretholdes, hvordan operationer udføres på det fysiske niveau.

Hvis DBMS sørger for at opretholde den logiske konsistens af transaktioner (og databasen), så bliver applikationer enklere, mere forståelige og mere pålidelige. Al logikken i applikationsområdet (bank, butik, lager osv.) vedrørende transaktioner og dataenes gyldige tilstand går ind i databasesystemet. Og kravene til dette system er meget enkle: understøttelse af ACID-transaktioner under hensyntagen til konsistensreglerne, som applikationen leverer i databasen. Fra mit synspunkt skaber afvisningen af ​​ACID-transaktioner umådelige vanskeligheder for applikationsudviklere, som, uanset om du kan lide det eller ej, selv bliver nødt til at implementere noget lignende for at tilfredsstille deres kunders naturlige behov.

Og endnu en gang bemærker jeg, at ACID-egenskaberne faktisk definerer begrebet en transaktion. Efter min mening, for i det mindste at have en vis mulighed for at tale om et transaktionsdatastyringssystem, hvor egenskaben transaktionskonsistens ikke understøttes, er det absolut nødvendigt at definere, hvad der menes med udtrykket transaktion i dette tilfælde.

Desværre taler man i dag i mange tilfælde (især dette er karakteristisk for NoSQL-retningen) om at understøtte OLTP-applikationer uden overhovedet at specificere, hvilken slags transaktioner de betyder. Derfor vil jeg i denne artikel bruge kombinationen ACID-transaktion til at henvise til reelle transaktioner, og det ukvalificerede udtryk transaktion vil blive brugt i en uformel betydning, forskellig i forskellige sammenhænge.

Lad os nu beskæftige os med "sætningen" af CAP og prøve at finde ud af, hvad konsekvens betyder i Brewers forstand.