DFU 04, ACID & BASE

# DFU 04
## ACID & BASE i Databaser

---

## Introduktion
- Hvad er en **transaktion**?  
- Hvorfor er transaktioner vigtige?  
- Overblik over ACID og BASE

---

## Transaktioner
Gentaget fra sidst

- **Definition**: En sekvens af operationer som enten fuldføres eller rulles tilbage  
- Eksempler:  
  - Bankoverførsel  
    - Lageropdatering

----

### Opgave 1

Tænk på et system, hvor du har brug for at opdatere flere tabeller på én gang.

- Hvilke problemer kan opstå uden transaktioner?  
    - f.eks. delvise opdateringer, inkonsistente data
- Hvordan kan transaktioner hjælpe med at løse disse problemer?
    - Findes der situationer, hvor transaktioner kan skabe problemer?
    - f.eks. ydeevne, table locks
- Er der situationer, hvor transaktioner ikke er nødvendige?
    - Hvad med dangling rows eller delvise opdateringer?

---

## ACID

----

### Hvad betyder ACID?

- Atomicity (Atomaritet)
- Consistency (Konsistens)
- Isolation (Isolation)
- Durability (Holdbarhed)

----

### ACID: Atomicity

- Hele transaktionen sker eller ingen del sker  
- Eksempel:  
    ```sql
    BEGIN;
    UPDATE accounts SET balance = balance - 100 WHERE id = 1;
    UPDATE accounts SET balance = balance + 100 WHERE id = 2;
    COMMIT;
    ```
- Hvis en fejl opstår: `ROLLBACK`

----

## ACID: Consistency

- Databasen går fra én gyldig tilstand til en anden  
- Constraints, triggers, foreign keys sikrer konsistens  
- Eksempel: saldo kan ikke være negativ

----

## ACID: Isolation

- Transaktioner påvirker ikke hinanden under udførelse  
- Isolation levels:  
  1. Read uncommitted  
    2. Read committed  
      3. Repeatable read  
        4. Serializable

----

### Read uncommitted

- Laveste niveau
- Tillader "dirty reads"
- Høj ydeevne, lav integritet

----

### Read committed

- Standard i mange DBMS
- Ingen dirty reads
- Tillader non-repeatable reads
- Balanceret ydeevne og integritet

----

### Repeatable Read

- Ingen non-repeatable reads
- Tillader phantom reads
  - Phantom reads er når nye rækker tilføjes af andre transaktioner og påvirker resultaterne af en tidligere læsning
- Højere integritet, lavere ydeevne

----

### Serializable

- Højeste niveau
- Ingen dirty reads, non-repeatable reads, eller phantom reads
- Simulerer sekventiel udførelse
- Lav ydeevne, høj integritet

----

### Opgave 2

15 min. med sidekammerat

Diskuter:

- Hvilken isolation level vil du vælge for en bankapplikation?  
- Hvorfor?

----

### ACID: Durability
- Når en transaktion er committed, overlever den systemfejl  
- Databasen gemmer på disk, logfiler sikrer genopretning

----

### Fordele ved ACID
- Høj dataintegritet  
- Forudsigelig opførsel  
- Velegnet til finansielle systemer og kritiske data

----

### Ulemper ved ACID
- Kan være langsommere  
- Svært at skalere horisontalt i distribuerede systemer

---

## Document Database

----

### Hvad er en Document Database?

- Lagrer data som dokumenter (f.eks. JSON, BSON)

- Fleksibelt skema

- Eksempler: MongoDB, CouchDB

- Velegnet til ustrukturerede data og hurtig udvikling

----

### Fordele ved Document Databases

- Fleksibelt skema

- Let at skalere horisontalt

- Hurtig udvikling og iteration

- God til hierarkiske data

----

### Ulemper ved Document Databases

- Manglende ACID transaktioner på tværs af dokumenter

- Sværere at håndtere komplekse forespørgsler

- Potentielt inkonsistente data

- Sjældent velegnet til relationelle data

----

### Hvornår bruge Document Databases?

- Hurtig udvikling med skiftende krav

- Ustrukturerede eller semi-strukturerede data

- Behov for horisontal skalering

- Eksempler: CMS, produktkataloger, IoT data

----

![Horizontal vs Vertical Scaling](/assets/dfu/dfu-horizontal-vertical-scaling.webp)

----

### Fordele ved horisontal skalering

- Tilføj flere maskiner for at håndtere belastning

- Bedre fejltolerance

- Skalerer bedre med store datamængder

- Ofte billigere end vertikal skalering

----

### Ulemper ved horisontal skalering

- Mere kompleksitet i systemdesign

- Data konsistens kan være sværere at opretholde

- Netværkslatens kan påvirke ydeevnen

- Virker sjældent med relationelle databaser

----

### Fordele ved vertikal skalering

- Simpelt at implementere

- Bevarer ACID egenskaber hvis muligt

- Mindre kompleksitet i systemdesign

----

### Ulemper ved vertikal skalering

- Begrænset af hardware kapaciteter

- Højere omkostninger ved opgradering

- Enkelt fejlpunkt (eller få)

----

### Document database eksempler (MongoDB)

```javascript
db.users.insertOne({ name: "Alice", age: 30, address: { city: "Copenhagen", zip: "1000" } });
db.users.find({ "address.city": "Copenhagen" });
```

- Indsæt og forespørg på dokumenter med indlejrede strukturer
- Fleksibelt skema, let at ændre dataformat

----

### Document database sharding

- Del data på tværs af flere servere (shards)

- Eksempel: brug `userId` som shard key

- Fordele: skalerer læse- og skriveoperationer

- Udfordringer: kompleksitet i forespørgsler og konsistens

---

## BASE

----

### BASE: Basically Available, Soft state, Eventually consistent
- Fokus på høj tilgængelighed og skalering  
- Ikke streng konsistens altid  
- Eksempler: NoSQL databaser  
  - Document: MongoDB  
    - Key/Value: Redis  
      - Wide column: Cassandra

----

### BASE: Basically Available
- Systemet svarer altid (tilgængeligt), selv ved netværksfejl

----

### BASE: Soft state
- Tilstand kan ændre sig over tid, før endelig konsistens

----

### BASE: Eventually consistent
- Data vil til sidst blive konsistent  
- Eksempel: sociale medier feeds, caches

----

### Opgave 3

15 min. med sidekammerat

Diskuter:  
- Hvornår ville du vælge BASE fremfor ACID?  
- Hvilke typer applikationer passer bedst?

---

### ACID vs BASE

----

### Brugsscenarier: Relationelle databaser

- PostgreSQL, MySQL, Oracle  
- ACID  
- Eksempel: banktransaktioner, ordrebehandling  
- Hvorfor: høj integritet og konsistens

----

### Brugsscenarier: Document databaser

- MongoDB  
- BASE-principper  
- Eksempel: produktkatalog, content management  
- Hvorfor: fleksibel skema, let skalering

----

### Brugsscenarier: Key/Value databaser

- Redis, DynamoDB  
- BASE, høj tilgængelighed  
- Eksempel: session storage, caching  
- Hvorfor: ekstremt hurtig adgang til simple data

----

### Opgave 4

Giv et eksempel på en applikation til hver database type, og forklar om den skal bruge ACID eller BASE.

----

### Kodeeksempel: ACID i PostgreSQL

```sql
BEGIN;
INSERT INTO orders(user_id, product_id) VALUES (1, 10);
UPDATE products SET stock = stock - 1 WHERE id = 10;
COMMIT;
```
- Hvis noget går galt: `ROLLBACK`  
- Forklaring:
    - Begynd en transaktion  
    - Indsæt ordre  
    - Opdater lager  
    - Commit eller rollback ved fejl med det samme

----

### Kodeeksempel: BASE i MongoDB

```javascript
db.orders.insertOne({ userId: 1, productId: 10 });
db.products.updateOne({ _id: 10 }, { $inc: { stock: -1 } });
```
- Tilgængelighed først, eventual consistency  
- Forklaring:
    - Indsæt ordre uden transaktion  
    - Opdater lager, kan være midlertidigt inkonsistent
    - Systemet vil til sidst blive konsistent

---

### Opsummering: ACID

- Atomicity, Consistency, Isolation, Durability  
- Høj integritet, lavere skalering  
- Velegnet til kritiske systemer

---

### Opsummering: BASE

- Basically Available, Soft state, Eventually consistent  
- Høj tilgængelighed, let skalering, tolererer midlertidig inkonsistens

---

### Diskussion

med sidekammerat

- Hvornår vil du vælge ACID fremfor BASE i praksis?  
  - Er der situationer hvor BASE kan bruges i relationelle databaser?
  - Kan ACID implementeres i NoSQL databaser?
- Hvordan påvirker valget systemets design og skalering?

----

### Document database vs. Relationel database

---

### Opg. i ACID

- Design et diagram for en bankapplikation med konti og transaktioner
- Generer den nødvendige SQL kode til at oprette tabellerne
- Indsæt data og vis eksempler på transaktioner
- Vis hvordan ACID egenskaberne sikrer dataintegritet ved overførsler mellem konti
- Opret eksempler med SQL kode for transaktioner
- Undersøg om der findes andre database systemer der understøtter ACID

---

### Opg. i BASE

- Design et diagram for et socialt medie feed system samt brugere, opslag, kommentarer og reactions (e.g. likes og dislikes) (Til Esbens like)
- Generer den nødvendige NoSQL kode til at oprette collections og indsætte dokumenter
- Indsæt data og vis eksempler på opslag, kommentarer og reactions
- Vis hvordan BASE egenskaberne sikrer høj tilgængelighed og skalerbarhed ved opslag og kommentarer
- Opret eksempler med NoSQL kode for opslag, kommentarer og reactions
- Undersøg om der findes andre database systemer der understøtter BASE