53 lines
1.2 KiB
Markdown
53 lines
1.2 KiB
Markdown
![[8-AltDM.pdf]]
|
|
|
|
![[Pasted image 20260723200735.png]]
|
|
|
|
|
|
**Scale Up** - Stärkerer Server - CPU, RAM, Disk... - Single-Point-of-failure
|
|
**Scale Out** - Last auf mehr Server Verteilen - hohe Skalierbarkeit - Betrieb schwieriger
|
|
|
|
### Sharding
|
|
Datenbank in kleine logische Teile aufteilen
|
|
- jede Shard eigener Server
|
|
- Sharding Key für wer wohin
|
|
|
|
+paralleles Verarbeiten
|
|
-schlechter Key erzeugt überlast
|
|
-Koordination
|
|
-Neuverteilung bei Wachstum
|
|
|
|
![[Pasted image 20260723201457.png]]
|
|
|
|
#### Two-Phase Commit 2PC
|
|
**Verteilte Atomarität** - Verteilte Transaktion wird auf ALLEN Systemen committed oder aborted!
|
|
Koordinator benötigt!
|
|
Stark wenn Atomarität wichtiger ist als Verfügbarkeit!
|
|
|
|
|
|
### CAP-Theorem
|
|
Konsistenz steht in Konflikt mit Verfügbarkeit
|
|
|
|
![[Pasted image 20260723203103.png]]
|
|
|
|
Im Fehlerfall muss zwischen C und A entschieden werden!
|
|
|
|
|
|
|
|
## BASE und NoSQL
|
|
BASE beschreibt schwächere skalierbare Garantien
|
|
NoSQL ist eine Systemfamilie
|
|
|
|
BASE = Basically Available, Soft State, Eventually Consistent
|
|
- System antwortet auch bei Teilausfall
|
|
- Zustandsänderung ohne neues Nutzerupdate
|
|
- Temporäre Inkonsistenz wird akzeptiert
|
|
|
|
NoSQL = Not Only SQL - Ergänzung statt Ersatz
|
|
Nicht nur Relationale Datenmodelle
|
|
Schemaflexibel
|
|
Systemfamilien
|
|
|
|
|
|
|
|
|