ACID-transaktioner

Teori

Fire egenskaber der garanterer pålidelige databasetransaktioner: Atomicitet, Konsistens, Isolation, Varighed.

Beskrivelse

ACID er et akronym for fire fundamentale egenskaber der garanterer at databasetransaktioner er pålidelige og konsistente selv ved fejl eller samtidig adgang. Atomicitet betyder at en transaktion enten sker helt eller slet ikke - ingen delvise opdateringer. Konsistens sikrer at databasen altid er i en gyldig tilstand før og efter transaktionen. Isolation betyder at samtidige transaktioner ikke påvirker hinanden. Varighed garanterer at committede ændringer overlever systemnedbrud. ACID er fundamentet for traditionelle relationelle databaser som PostgreSQL og MySQL og er kritisk for applikationer hvor dataintegritet er afgørende - banking, e-handel, bookingsystemer. Dog kommer ACID med ydeevne-afvejninger: strenge isolationsniveauer og varighedsgarantier kan reducere gennemløb. Moderne systemer balancerer ofte ACID-garantier med ydeevne - NoSQL-databaser vælger ofte eventual consistency over streng ACID for bedre skalering.

Problem

Uden ACID-garantier kan databaseoperationer fejle på upålidelige måder: penge kan forsvinde ved overførsler, lagerbeholdning kan blive negativ, eller to brugere kan booke samme sæde. Samtidig adgang og systemnedbrud kan korrumpere data.

Løsning

ACID-transaktioner wrapper flere operationer så de behandles som én atomisk enhed. Databasen bruger write-ahead logging, låsning og MVCC til at håndhæve ACID-egenskaber og sikre dataintegritet.

Eksempel

-- Bank transfer eksempel uden transaction (FARLIGT!)
UPDATE accounts SET balance = balance - 500 WHERE account_id = 1;
-- Hvis system crasher HER, er penge væk!
UPDATE accounts SET balance = balance + 500 WHERE account_id = 2;

-- Med ACID transaction (SIKKERT)
BEGIN TRANSACTION;
  -- Atomicity: Begge updates eller ingen
  UPDATE accounts SET balance = balance - 500 
  WHERE account_id = 1;
  
  UPDATE accounts SET balance = balance + 500 
  WHERE account_id = 2;
  
  -- Consistency: Check business rule
  IF (SELECT balance FROM accounts WHERE account_id = 1) < 0 THEN
    ROLLBACK; -- Anuller alt
  ELSE
    COMMIT; -- Gem begge changes permanent
  END IF;
END TRANSACTION;

-- Isolation levels
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;
  -- Denne transaction ser ikke uncommitted changes fra andre
  SELECT * FROM products WHERE id = 123 FOR UPDATE;
  -- Lock row så andre må vente
  UPDATE products SET stock = stock - 1 WHERE id = 123;
COMMIT;

-- Durability demonstration
BEGIN TRANSACTION;
  INSERT INTO orders (user_id, total) VALUES (1, 999.99);
  COMMIT; -- Nu garanteres data gemt selv ved system crash
-- Data overlever power failure pga. write-ahead log

Fordele

✓Garanteret dataintegritet
✓Ingen delvise opdateringer eller korrumperet tilstand
✓Sikker samtidig adgang
✓Gendannelse efter systemfejl
✓Forretningslogik-begrænsninger håndhæves

Udfordringer

⚠Ydeevne-overhead fra låsning
⚠Reduceret gennemløb ved høj samtidighed
⚠Kompleksitet i distribuerede systemer
⚠Deadlocks kan forekomme
⚠Ikke altid nødvendigt for alle brugsscenarier

Anvendelsesområder

•Finansielle transaktioner og banking
•E-handel ordrebehandling
•Bookingsystemer (hoteller, flybilletter)
•Lagerstyring
•Flerbrugerapplikationer med samtidige skrivninger

Eksempler fra den virkelige verden

•Bankoverførsler (begge konti opdateres eller ingen)
•Online shopping checkout (lager, betaling, ordreoprettelse)
•Flybooking (sædeallokering må ikke dobbeltbooke)
•Kasinospil (saldoopdateringer skal være præcise)
•Medicinske journaler (kritisk datakonsistens)