Multi-Phase Multiway Merge-Sort und B+-Baum-Indizes: CSC370-Datenbankaufgabe

Einführung in die CSC370-Datenbankaufgabe

Die CSC370-Datenbankaufgabe behandelt zentrale Konzepte der Datenbankverwaltung: Sortieren großer Datenmengen, Indexstrukturen, Abfragekosten und Transaktionssperrprotokolle. In diesem Tutorial erklären wir die Grundlagen des Multi-Phase Multiway Merge Sort (MPMMS), den Aufbau von B+-Bäumen und die Funktionsweise von Shared/Exclusive/Update-Locks. Stell dir vor, du organisierst die Rangliste eines großen E-Sport-Turniers mit Millionen von Spielern – genau wie beim Sortieren von 10.000.000 Blöcken in der Aufgabe.

Phase 1: Sortierte Läufe erzeugen

Gegeben: Eine Festplatte mit einer durchschnittlichen Suchzeit von 10 ms, einer durchschnittlichen Rotationslatenz von 5 ms und einer Transferzeit von 1 ms pro 4KB-Block. Die Kosten für einen Lese-/Schreibzugriff betragen 16 ms. Die Relation umfasst 10.000.000 Blöcke, und der verfügbare Hauptspeicher für Puffer beträgt 320 Blöcke.

Im ersten Schritt erzeugen wir sortierte Läufe der Größe 320 Blöcke. Jeder Lauf wird durch Einlesen von 320 Blöcken, Sortieren im Speicher und Zurückschreiben erzeugt. Die Anzahl der Läufe ist:

Anzahl Läufe = ⌈10.000.000 / 320⌉ = 31.250

Die Kosten für Phase 1: Jeder Block wird einmal gelesen und einmal geschrieben, also 2 * 10.000.000 * 16 ms = 320.000.000 ms = 320.000 Sekunden.

Phase 2 und folgende: 319-fach Merge

Da der Speicher 320 Blöcke fasst, können wir 319 Eingabeläufe gleichzeitig mergen (ein Block pro Eingabe, ein Block für die Ausgabe). Die Anzahl der Phasen ergibt sich aus der Anzahl der Läufe pro Merge-Schritt:

Phasen = ⌈log_{319}(31.250)⌉ + 1 = ⌈log_{319}(31.250)⌉ + 1

Berechnung: 319^2 = 101.761, 319^3 = 32.461.759. Da 31.250 zwischen 319^2 und 319^3 liegt, benötigen wir 3 Phasen (Phase 1 + 2 Merge-Phasen).

Kosten pro Merge-Phase: Jeder Block wird einmal gelesen und einmal geschrieben, also wieder 2 * 10.000.000 * 16 ms pro Phase. Für 2 Merge-Phasen also 640.000.000 ms. Gesamtkosten: 320.000.000 ms + 640.000.000 ms = 960.000.000 ms = 960.000 Sekunden ≈ 11,1 Tage.

B+-Baum mit n=3 aufbauen

Ein B+-Baum mit der Ordnung n=3 kann maximal 3 Schlüssel pro Knoten speichern. Wir fügen die Schlüssel 2, 15, 31, 32, 6, 18, 19, 20, 3, 4, 5, 40, 41, 42 nacheinander ein. Hier der Ablauf:

Einfügen 2: [2]
Einfügen 15: [2,15]
Einfügen 31: [2,15,31]
Einfügen 32: Überlauf → Split: [15] als Wurzel, linkes Blatt [2], rechtes Blatt [31,32]
Einfügen 6: in linkes Blatt → [2,6]
Einfügen 18: in rechtes Blatt → [18,31,32] (Überlauf? Nein, da 3 erlaubt)
Einfügen 19: in rechtes Blatt → [18,19,31,32] Überlauf → Split: [19,31] in Wurzel? Wurzel [15] wird zu [15,19,31], linkes Blatt [18], rechtes Blatt [31,32]
... (weitere Einfügungen analog)

Nach allen Einfügungen ergibt sich ein balancierter Baum mit Höhe 2.

Abfragekosten berechnen

Die Kosten einer Abfrage werden in I/Os gemessen. Bei einer Sort-Merge-Join-Operation werden beide Relationen sortiert und dann gemerged. Wenn die linke Selektion klein ist und im Speicher gehalten wird, entfallen die I/Os für das Sortieren dieser Seite. Die rechte Selektion wird pipelined, d.h. die sortierten Teillisten werden on-the-fly erzeugt. Die Gesamtkosten setzen sich aus dem Lesen der Blöcke beider Relationen plus dem Schreiben der Zwischenergebnisse zusammen – außer dem finalen Ergebnis.

Transaktionssperrprotokolle verstehen

Stell dir vor, mehrere Spieler in einem Online-Battle-Royale greifen gleichzeitig auf dieselbe Waffe zu – das erfordert Locks. Bei Shared Locks (Sperre zum Lesen) können mehrere Transaktionen gleichzeitig lesen, aber niemand schreiben. Exklusive Locks (X) erlauben nur einer Transaktion das Schreiben. Update Locks (U) verhindern Deadlocks, wenn eine Transaktion zuerst liest und später schreibt.

In der Aufgabe werden für verschiedene Schedules die Locks eingefügt. Beispiel: Bei Schedule 1 (r1(A); r2(B); r3(C); r1(B); r2(C); r3(D); w1(A); w2(B); w3(C)) führt ein Shared Lock vor jedem Lesen und ein Exklusiv Lock vor jedem Schreiben zu einem Deadlock, wenn T1 auf A wartet, T2 auf B, T3 auf C. Mit Upgrade (Shared→Exklusiv) oder Update Locks kann der Deadlock vermieden werden.

UNDO/REDO-Logs und Checkpoints

Ein UNDO-Log zeichnet alte Werte auf, um Transaktionen rückgängig zu machen. Ein REDO-Log zeichnet neue Werte auf, um sie nach einem Crash wiederherzustellen. Bei einem nicht-quieszenten Checkpoint werden alle aktiven Transaktionen notiert, während das System weiterläuft. Nach einem Crash muss das Log ab dem letzten [END CKPT] oder früher durchsucht werden, um alle unvollständigen Transaktionen zu finden.

BCNF und Normalisierung

Die Boyce-Codd-Normalform (BCNF) verlangt, dass für jede nicht-triviale funktionale Abhängigkeit X→Y gilt: X ist ein Superschlüssel. Verstöße werden durch Dekomposition behoben. Beispiel: Bei FD A→B, B→C, C→D, D→A ist jede Determinante ein Superschlüssel, also liegt BCNF vor. Bei AB→C, B→D, CD→A, AD→B ist B→D ein Verstoß, weil B kein Superschlüssel ist. Dekomposition in R1(B,D) und R2(A,B,C) mit FD AB→C, CD→A, AD→B.

Fazit

Die CSC370-Datenbankaufgabe deckt die wichtigsten Themen der Datenbankverwaltung ab. Mit dem Verständnis von Multi-Phase Multiway Merge Sort, B+-Bäumen, Sperrprotokollen und Logging bist du gut gerüstet, um ähnliche Aufgaben zu lösen. Übe die Konzepte anhand der gegebenen Zahlen und Schedules – so wie ein E-Sport-Profi seine Strategien trainiert.