ACID-transacties

Wat zijn ACID-transacties?

Een transactie is een groepje bewerkingen dat als één geheel slaagt of faalt. ACID staat voor de vier garanties die een database daarbij geeft: Atomicity, Consistency, Isolation en Durability. Samen zorgen ze ervoor dat je data correct blijft, ook als er iets misloopt of als tien processen tegelijk schrijven.

Het klassieke voorbeeld is een overschrijving. Je haalt honderd euro van rekening A en zet ze op rekening B. Dat zijn twee bewerkingen, maar voor de bank is het één transactie. Slaagt de eerste en crasht de server voor de tweede, dan mag dat geld niet verdampen. ACID garandeert dat beide bewerkingen samen doorgaan, of geen van beide.

De vier letters van ACID

Atomicity (ondeelbaarheid)
Een transactie gaat volledig door of helemaal niet. Er bestaat geen tussentoestand waarin de helft geschreven is. Loopt stap drie van de vijf vast, dan draait de database de eerste twee terug.

Consistency (consistentie)
Na elke transactie voldoet de data nog aan alle regels: geen negatieve voorraad, geen order zonder klant, geen dubbele sleutel. Een transactie brengt de database van de ene geldige toestand naar de andere, nooit naar een kapotte tussentoestand.

Isolation (isolatie)
Draaien er meerdere transacties tegelijk, dan zien ze elkaars half werk niet. Elke transactie werkt alsof ze alleen op de database bezig is. Zo tellen twee processen niet per ongeluk hetzelfde bedrag dubbel en overschrijven ze elkaars wijziging niet.

Durability (duurzaamheid)
Zodra een transactie bevestigd is, staat ze vast. Valt daarna de stroom uit of crasht de machine, dan is het resultaat niet verloren. De wijziging is naar duurzame opslag weggeschreven voordat de bevestiging terugkomt.

Wat er misgaat zonder ACID

Neem een nachtelijke load die je verkooptabel bijwerkt. Het proces gooit de oude rijen weg en schrijft de verse cijfers uit de webshop en het kassasysteem terug. Halverwege valt de verbinding weg.

Zonder ACID blijf je achter met een halve tabel: de oude cijfers deels weg, de nieuwe deels binnen. Wie 's ochtends een rapport opent, ziet een omzet die nergens op slaat. Erger nog, je weet niet eens dat de tabel stuk is, want er kwam geen foutmelding op je scherm. Met ACID gebeurt dat niet: ofwel staat de volledige nieuwe load erin, ofwel de volledige oude. Nooit een mengeling van de twee.

Een tweede klassieker: twee processen schrijven tegelijk naar dezelfde tabel. Beide lezen ze de tabel, beide schrijven ze hun versie terug, en de laatste die klaar is plakt over het werk van de andere heen. Eén van de twee updates is spoorloos, zonder dat iemand het merkt. Isolatie en concurrency-controle zijn net wat dat tegenhoudt.

Van database naar data lake

ACID zat historisch enkel in databases. Een systeem als PostgreSQL, SQL Server of Oracle beheert zelf zijn bestanden en houdt met vergrendeling en een write-ahead log strikt bij wie wat wanneer wijzigt. Eén motor bewaakt alles, dus transacties zitten er ingebakken.

Een data lake werkt anders. Daar staan losse bestanden, meestal Parquet, op object storage zoals Azure Blob of Amazon S3. Object storage kent geen transacties: het weet alleen van bestanden die je neerzet, vervangt of wist. Schrijft een job de helft van een tabel en crasht ze dan, dan blijven er half geschreven bestanden staan. En twee schrijvers die elkaar overlappen, hebben geen scheidsrechter.

Open tabelformaten lossen dat op. Delta Lake, Apache Iceberg en Apache Hudi leggen een transactielog naast de databestanden. Die log is de enige waarheid over welke bestanden bij welke versie van de tabel horen. Zo krijgen bestanden op object storage dezelfde ACID-garanties als een klassieke database, via drie ingrediënten:

• Transactielog
  Een wijziging telt pas zodra ze in de log staat. Crasht een job voordat de log-entry geschreven is, dan tellen haar bestanden gewoon niet mee. Dat geeft je atomiciteit.

• Snapshot-isolatie
  Een lezer krijgt de tabel zoals ze was toen zijn query startte, ook als er ondertussen geschreven wordt. Niemand ziet half werk.

• Optimistic concurrency
  Schrijvers werken door in de veronderstelling dat ze elkaar niet in de weg zitten. Net voor het bevestigen checkt het formaat of er sinds de start iets conflicterends gecommit is. Bij een conflict faalt de tweede schrijver met een foutmelding, in plaats van stilletjes over de eerste te plakken.

ACID in een database versus in een lakehouse

Het eindresultaat is hetzelfde, correcte data ook bij crashes en gelijktijdig schrijven, maar de weg erheen verschilt.

In een klassieke OLTP-database bewaakt één motor alles. Vergrendeling en een centrale log regelen de volgorde, transacties gaan over milliseconden en raken vaak maar enkele rijen. Het model is gebouwd voor veel kleine schrijfacties per seconde.

In een lakehouse ligt de data als bestanden op object storage en neemt de transactielog van het tabelformaat de rol van scheidsrechter over. Transacties gaan hier over grotere brokken, zoals een hele nachtelijke load of een merge van duizenden rijen, en draaien in seconden tot minuten. De garantie is dezelfde, de korrel is groter. Vandaar dat een lakehouse ACID biedt voor je analyses, terwijl je operationele app nog altijd op een echte transactionele database draait.