SYRE konsept

3.1 Fremkomst av SYRE

Forkortelsen ACID dukket opp første gang i 1983 i en artikkel av Theo Haerder og Andreas Reuter. For å forenkle teksten og gjøre den mer overbevisende, vil jeg gi en oversettelse av et fragment av denne artikkelen (med små reduksjoner). Denne kodebiten bruker et eksempel på en banktransaksjon der penger overføres fra en konto til en annen.

Konseptet med en transaksjon, som i eksemplet inkluderer alle interaksjoner med databasen mellom $BEGIN_TRANSACTIONog $COMMIT_TRANSACTION, krever at alle handlinger utføres udelelig: enten reflekteres alle handlinger riktig i databasens tilstand, eller så skjer ingenting. $COMMIT_TRANSACTIONHvis brukeren på et tidspunkt før han når frem til en setning ERRORsom inneholder $RESTORE_TRANSACTION, gjenspeiles ingen endringer i databasen.

For å oppnå denne udeleligheten må en transaksjon ha følgende fire egenskaper:

Atomisitet (Atomisitet). Transaksjonen må være av alt-eller-ingenting-typen beskrevet ovenfor, og uansett hva som skjer, må brukeren vite hvilken tilstand transaksjonen er i.

Konsistens (Konsistens). En transaksjon som når sin normale transaksjonsslutt (EOT) og dermed forplikter sine resultater opprettholder databasekonsistens. Med andre ord, hver vellykket transaksjon, per definisjon, forplikter kun gyldige resultater. Denne tilstanden er nødvendig for å støtte den fjerde egenskapen - holdbarhet.

Isolasjon (Isolasjon). Hendelser som oppstår i en transaksjon må skjules fra andre transaksjoner som utføres samtidig. Hvis denne betingelsen ikke var oppfylt, ville transaksjonen av grunnene nevnt ovenfor være umulig å gå tilbake til begynnelsen. For å oppnå isolasjon brukes metoder kalt synkronisering ...

Durability (Durability). Når en transaksjon har fullført og forpliktet resultatene til databasen, må systemet sikre at disse resultatene overlever eventuelle påfølgende feil. Siden det ikke er noen kontrollomfang som spenner over sett med transaksjoner, har databasestyringssystemet (DBMS) ingen kontroll utover grensene for transaksjoner.

Derfor må brukeren være garantert at dersom systemet informerer ham om at noe har skjedd, så har dette "noe" virkelig skjedd. Siden enhver (vellykket fullført - S.K.) transaksjon per definisjon er korrekt, kan resultatene av uunngåelig forekommende feiltransaksjoner (dvs. transaksjoner som inneholder feilaktige data) bare elimineres av den tilsvarende "mottransaksjonen" (mottransaksjon).

3.2 Fremveksten av transaksjoner

Disse fire egenskapene – Atomicity, Consistency, Isolation og Durability (ACID) – beskriver kjernetrekkene i transaksjonsparadigmet som påvirker mange aspekter av databasesystemdesign. Derfor tror vi at evnen til ethvert system til å støtte transaksjoner er prøvesteinen (ACID-testen) for kvaliteten på dette systemet.

Et enkelt PL/1-SQL-program som overfører penger fra en konto til en annen.

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 ga et eksempel på denne koden for å minne deg på at faktisk ACID-egenskaper på den ene siden kan betraktes som krav for enhver DBMS som hevder å støtte transaksjoner, og på den annen side som definisjonen av en transaksjon i et databasesystem . Denne definisjonen stemmer helt overens med verdslig praksis. Det er for eksempel vanskelig å forestille seg at en kunde som utfører en banktransaksjon (enten ved hjelp av en menneskelig teller eller bruker nettbank) ikke forventer at banken tilfredsstiller alle egenskapene til ACID. En bank som ikke støtter ACID-egenskaper for sine transaksjoner vil i beste fall miste kunder, og i verste fall gå konkurs.

3.3 ACID-tilkobling

Det er veldig viktig at ACID-egenskapene er uadskillelige, å forkaste noen av dem gjør den gjenværende kombinasjonen meningsløs. Spesielt hvis vi forkaster konsistensegenskapen (i den betydningen den ble brukt i sitatet ovenfor), vil vi miste kriteriet for riktigheten av en transaksjon. Databasesystemet vil ikke kunne avgjøre på noen meningsfull måte om transaksjoner er tillatt eller ikke skal begås, og alle kontroller for riktigheten av operasjoner utført i gjeldende tilstand av databasen vil måtte utføres i applikasjonskode.

Du må forstå at i dette tilfellet snakker vi om logisk konsistens. Bankens klient trenger at banken jobber i henhold til reglene fastsatt av ham og kjent for kundene, slik at det er umulig å utføre noen transaksjon som bryter disse reglene, slik at den neste transaksjonen til samme klient utføres i en miljø avtalt i samsvar med disse reglene.

Kunden til nettbutikken trenger at varene som er bestilt og betalt av ham, skal leveres til ham i tide (i samsvar med reglene etablert og kjent for kunden). Ellers vil han ikke stole på denne butikken. Samtidig bryr verken bankens klient eller nettbutikkens klient seg om det interne kjøkkenet til bedriften, hvilke interne handlinger som tas for å fullføre transaksjonen. Kunden bryr seg ikke om hvordan den fysiske konsistensen til denne virksomheten opprettholdes, hvordan operasjoner utføres på fysisk nivå.

Hvis DBMS tar seg av å opprettholde den logiske konsistensen av transaksjoner (og databasen), blir applikasjonene enklere, mer forståelige og mer pålitelige. All logikken til applikasjonsområdet (bank, butikk, lager, etc.) angående transaksjoner og den gyldige tilstanden til dataene går inn i databasesystemet. Og kravene til dette systemet er veldig enkle: støtte for ACID-transaksjoner, tatt i betraktning konsistensreglene gitt i databasen av applikasjonen. Fra mitt synspunkt skaper avvisningen av ACID-transaksjoner umåtelige vanskeligheter for applikasjonsutviklere, som, enten du liker det eller ikke, må implementere noe lignende selv for å tilfredsstille kundenes naturlige behov.

Og nok en gang merker jeg at ACID-egenskapene faktisk definerer konseptet med en transaksjon. Etter min mening, for å ha i det minste noen mulighet til å snakke om et transaksjonsdatahåndteringssystem der egenskapen transaksjonskonsistens ikke støttes, er det helt nødvendig å definere hva som menes med begrepet transaksjon i dette tilfellet.

Dessverre snakker folk i dag i mange tilfeller (spesielt dette er karakteristisk for NoSQL-retningen), om å støtte OLTP-applikasjoner uten å spesifisere i det hele tatt hva slags transaksjoner de betyr. Derfor vil jeg i denne artikkelen bruke kombinasjonen ACID-transaksjon for å referere til reelle transaksjoner, og det ukvalifiserte begrepet transaksjon vil bli brukt i en uformell betydning, forskjellig i forskjellige sammenhenger.

La oss nå ta for oss "teoremet" til CAP og prøve å finne ut hva konsistens betyr i Brewers forstand.