3.1 Opkomst van ZUUR
De afkorting ACID verscheen voor het eerst in 1983 in een artikel van Theo Haerder en Andreas Reuter. Om de tekst te vereenvoudigen en overtuigender te maken, zal ik een vertaling geven van een fragment uit dit artikel (met kleine verkortingen). Dit fragment gebruikt een voorbeeld van een banktransactie waarbij geld van de ene rekening naar de andere wordt overgemaakt.
Het concept van een transactie, dat in het voorbeeld alle interacties met de database tussen $BEGIN_TRANSACTIONen omvat $COMMIT_TRANSACTION, vereist dat alle acties ondeelbaar worden uitgevoerd: ofwel worden alle acties correct weerspiegeld in de staat van de database, ofwel gebeurt er niets. Als de gebruiker op enig moment voordat hij bereikt wordt $COMMIT_TRANSACTIONeen verklaring invoert ERRORdie bevat $RESTORE_TRANSACTION, worden er geen wijzigingen doorgevoerd in de database.
Om deze ondeelbaarheid te bereiken, moet een transactie de volgende vier eigenschappen hebben:
Atomiciteit (Atomiciteit). De transactie moet van het hierboven beschreven type alles-of-niets zijn en wat er ook gebeurt, de gebruiker moet weten in welke staat de transactie zich bevindt.
Consistentie (Consistentie). Een transactie die het normale einde van de transactie (EOT) bereikt en daardoor de resultaten vastlegt, handhaaft de consistentie van de database. Met andere woorden, elke succesvolle transactie levert per definitie alleen geldige resultaten op. Deze voorwaarde is nodig om de vierde eigenschap te ondersteunen: duurzaamheid.
Isolatie (Isolatie). Gebeurtenissen die binnen een transactie plaatsvinden, moeten worden verborgen voor andere gelijktijdig uitgevoerde transacties. Als niet aan deze voorwaarde zou zijn voldaan, zou het om de bovengenoemde redenen onmogelijk zijn om terug te keren naar het begin van de transactie. Om isolatie te bereiken, worden methoden genaamd synchronisatie gebruikt ...
Duurzaamheid (duurzaamheid). Zodra een transactie is voltooid en de resultaten zijn vastgelegd in de database, moet het systeem ervoor zorgen dat die resultaten eventuele latere fouten overleven. Aangezien er geen reikwijdte van controle is die sets van transacties omvat, heeft het databasebeheersysteem (DBMS) geen controle buiten de grenzen van transacties.
Daarom moet de gebruiker gegarandeerd zijn dat als het systeem hem informeert dat er iets is gebeurd, dit "iets" echt is gebeurd. Aangezien elke (succesvol voltooide - S.K.) transactie per definitie correct is, kunnen de resultaten van onvermijdelijk verschijnende onjuiste transacties (d.w.z. transacties met foutieve gegevens) alleen worden geëlimineerd door de overeenkomstige "tegentransactie" (tegentransactie).
3.2 Het ontstaan van transacties
Deze vier eigenschappen - Atomiciteit, Consistentie, Isolatie en Duurzaamheid (ACID) - beschrijven de kernkenmerken van het transactionele paradigma die veel aspecten van het ontwerp van databasesystemen beïnvloeden. Daarom zijn wij van mening dat het vermogen van elk systeem om transacties te ondersteunen de toetssteen (ACID-test) is van de kwaliteit van dit systeem.
Een eenvoudig PL/1-SQL-programma dat geld overmaakt van de ene rekening naar de andere.
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 */Ik heb een voorbeeld van deze code gegeven om u eraan te herinneren dat ACID-eigenschappen enerzijds kunnen worden beschouwd als vereisten voor elk DBMS dat claimt transacties te ondersteunen, en anderzijds als de definitie van een transactie in een databasesysteem . Deze definitie is volledig in overeenstemming met de wereldse praktijk. Het is bijvoorbeeld moeilijk voor te stellen dat een klant die een banktransactie uitvoert (hetzij met de hulp van een live menselijke teller of via internetbankieren) niet verwacht dat de bank aan alle eigenschappen van ACID voldoet. Een bank die ACID-eigendommen niet ondersteunt voor zijn transacties, zal in het beste geval klanten verliezen en in het slechtste geval failliet gaan.
3.3 ACID-connectiviteit
Het is erg belangrijk dat de ACID-eigenschappen onafscheidelijk zijn, het weggooien van een van hen maakt de resterende combinatie zinloos. Als we met name de eigenschap consistentie weggooien (in de zin waarin deze in het bovenstaande citaat werd gebruikt), verliezen we het criterium voor de juistheid van een transactie. Het databasesysteem zal op geen enkele zinvolle manier kunnen beslissen of transacties al dan niet mogen worden vastgelegd, en alle controles op de juistheid van bewerkingen die worden uitgevoerd in de huidige staat van de database zullen moeten worden uitgevoerd in applicatiecode.
U moet begrijpen dat we het in dit geval hebben over logische consistentie. De klant van de bank wil dat de bank werkt volgens de regels die door hem zijn opgesteld en bekend zijn bij de klanten, zodat het onmogelijk is om een transactie uit te voeren die in strijd is met deze regels, zodat de volgende transactie van dezelfde klant wordt uitgevoerd in een omgeving overeengekomen in overeenstemming met deze regels.
De klant van de webwinkel dient de door hem bestelde en betaalde goederen tijdig (volgens de bij de klant vastgestelde en bekende regels) bij hem te bezorgen. Anders vertrouwt hij deze winkel niet. Tegelijkertijd geeft noch de klant van de bank, noch de klant van de internetwinkel om de interne keuken van de onderneming, welke interne acties worden ondernomen om de transactie te voltooien. Het maakt de klant niet uit hoe de fysieke consistentie van deze onderneming wordt gehandhaafd, hoe operaties op fysiek niveau worden uitgevoerd.
Als het DBMS zorgt voor het handhaven van de logische consistentie van transacties (en de database), worden applicaties eenvoudiger, begrijpelijker en betrouwbaarder. Alle logica van het toepassingsgebied (bank, winkel, magazijn, enz.) met betrekking tot transacties en de geldige status van de gegevens gaat naar het databasesysteem. En de vereisten voor dit systeem zijn heel eenvoudig: ondersteuning voor ACID-transacties, rekening houdend met de consistentieregels die door de applicatie in de database worden verstrekt. Naar mijn mening creëert de afwijzing van ACID-transacties buitensporige moeilijkheden voor applicatieontwikkelaars, die, of je het nu leuk vindt of niet, zelf iets soortgelijks zullen moeten implementeren om aan de natuurlijke behoeften van hun klanten te voldoen.
En nogmaals merk ik op dat de ACID-eigenschappen in feite het concept van een transactie definiëren. Om op zijn minst enige mogelijkheid te hebben om te praten over een transactiegegevensbeheersysteem waarin de eigenschap van transactieconsistentie niet wordt ondersteund, is het naar mijn mening absoluut noodzakelijk om te definiëren wat in dit geval met de term transactie wordt bedoeld.
Helaas praten mensen tegenwoordig in veel gevallen (dit is met name kenmerkend voor de NoSQL-richting) over het ondersteunen van OLTP-applicaties zonder te specificeren wat voor soort transacties ze bedoelen. Daarom zal ik in dit artikel de combinatie ACID-transactie gebruiken om naar echte transacties te verwijzen, en de ongekwalificeerde term transactie zal in informele zin worden gebruikt, verschillend in verschillende contexten.
Laten we het nu hebben over de 'stelling' van CAP en proberen uit te zoeken wat consistentie betekent in de zin van Brewer.