Datenbank

Die meisten Datenbanken nutzen eine Sprache namens SQL (Structured Query Language), um mit ihnen zu reden. Ein Befehl sieht so aus: SELECT * FROM users WHERE age > 18; ("Gib mir alle Benutzer, die älter als 18 sind").

Man unterscheidet grob:

1. Relationale Datenbanken (SQL): Alles ist in strengen Tabellen organisiert (Zeilen und Spalten). Wie Excel. (Beispiele: MySQL, PostgreSQL, Microsoft SQL Server).
2. NoSQL Datenbanken: Viel freier. Man speichert Daten als Dokumente (wie JSON). Perfekt für unstrukturierte Daten. (Beispiele: MongoDB, Redis).

1. ACID (Die 4 heiligen Regeln)

Bei Bank-Transaktionen darf nichts schiefgehen. Wenn Geld von Konto A abgebucht wird, muss es auf Konto B ankommen. Wenn der Strom ausfällt, darf das Geld nicht verschwinden. Dafür gibt es ACID:

• Atomicity: Ganz oder gar nicht. (Keine halben Buchungen).
• Consistency: Die Datenbank bleibt immer logisch korrekt.
• Isolation: Parallele Transaktionen stören sich nicht.
• Durability: Wenn "Gespeichert" gesagt wurde, ist es auch nach einem Stromausfall noch da.

2. Indexing

Wie findet eine DB einen Namen unter 1 Milliarde Einträgen in 0,001 Sekunden? Sie nutzt einen Index (wie das Inhaltsverzeichnis in einem Buch). Statt alle Seiten zu lesen ("Full Table Scan"), schaut sie im Index nach "Müller -> Seite 4567". Der Index ist meist ein B-Tree (balancierter Baum).

1. The CAP Theorem

Das absolute Fundament für große, verteilte Datenbanken (z.B. MongoDB Cluster oder Cassandra). Es besagt, dass du in vernetzten Systemen von drei Eigenschaften immer nur maximal zwei haben kannst:

• Consistency: Alle Nodes (Server) lesen in derselben Millisekunde denselben neuen Wert.
• Availability: Die Datenbank stürzt niemals ab und kann immer Queries beantworten.
• Partition Tolerance: Die Server können weiterarbeiten, wenn ihr internes Netzwerkkabel zerschnitten wird ("Split Brain"). Wenn das Netzwerk ausfällt (P ist ein Muss), hast du die Wahl: Bleibst du online (A), antwortest aber vielleicht mit falschen, asynchronen Daten (kein C)? Oder fährst du den Server lieber hart herunter und wirfst 500er Errors, um garantiert keine inkonsistenten Daten zu lügen (C)? (Daher spricht man von AP oder CP Systemen).

2. ACID vs. BASE

Relationale DBs pochen auf ACID (Alles oder Nichts, absolut fehlerfreie Buchungen). Die Performance leidet bei Scale, wegen des starken Lockings. NoSQL DBs antworten darauf oft mit BASE (Basically Available, Soft state, Eventual consistency). Anstatt Daten beim Schreiben 100% quer über alle Cluster auf der ganzen Welt sofort zu verriegeln, schlüpft der Save rein, und der Node meldet "Okay!". Im Hintergrund synchronisieren sich die Nodes ("Eventual Consistency"). Das heißt, wenn ein User in Japan den Post liket, und ein Freund in Brasilien ruft 1 Sekunde später den Post ab, steht dort vielleicht noch "0 Likes", bis die Synchronisation "irgendwann" (Eventual) nachrutscht. Für Social Media ist BASE perfekt (Speed), für das Aktien/Bankenwesen absolutes Gift.

3. Write-Ahead Logging (WAL)

Wie garantiert Postgres "Durability" (D in ACID), dass nichts verloren geht bei Stromausfall? Jedes Mal wenn du etwas in die DB in Postgres schreibst, wird diese Zeile nicht sofort tief in die komplexen verschachtelten Speicher-Zellen der .mdf-Datei auf der HDD gespeichert (das Positionieren der Schreibköpfe dafür würde dauern). Stattdessen schreibt Postgres die Aktion als rohen Text Row x=5 stumpf asynchron ans Ende einer Endlos-Logdatei (WAL). Ein simples Append ans Ende geht auf der Platte in Nanosekunden ("Sequential Write"). Fällt nun der Strom aus, liest Postgres beim Hochbooten einfach ab dem Crash von unten nach oben diese WALs ("Was ist zuletzt alles passiert, aber noch nicht richtig sortiert abgeheftet worden?") und spielt (re-played) den RAM-Zustand exakt wieder ein, bevor der RAM ausging.