IMPLEMENTIERUNG VON OPERATIONEN AUF RELATIONEN

Joins 1 IMPLEMENTIERUNG VON OPERATIONEN AUF RELATIONEN Literatur Priti Mishara, Maragaret H. Eich, Join Processing in Relational Databases, ACM Computing Surveys, Vol. 24, No. 1, March 1992 Goetz Graefe, Query Evaluation Techniques for Large Databases, ACM Computing Surveys, Vol. 25, No. 2, June 1993

Joins 2 Abfrage-Auswertungs-Techniken Effiziente Algorithmen für die Auswertung von komplexen Abfragen an große Datenbanken. Eine große Datenbank in diesem Zusammenhang ist eine Datei mit mehreren (hundert) Megabytes.

Joins 3 Abfrageverarbeitung in einem Datenbanksystem: Benutzerschnittstelle (User Interface) Abfragesprache Abfrageoptimierer Abfrageausführungs- Einheit Dateien und Indizes I/O Puffer Festplatten

Joins 4 Abfrageoptimierer (Query Optimizer) Der Optimierer übersetzt eine Anfrage (SQL) in eine Sequenz von Operationen, die in der Ausführungseinheit oder dem Dateisystem implementiert sind. Ziel ist es, einen Anfrage-Ausführungsplan (query execution plan) zu finden, der den Verbrauch von CPU, I/O, Speicher etc. minimiert. Ausführungseinheit Die Ausführungseinheit ist eine Sammlung von Funktionen und Mechanismen zur Kommunikation und Synchronisation zwischen Operatoren.

Joins 5 Schritte bei der Ausführung einer Abfrage Parsing Anfrage-Validierung (Schema-Katalog) Sichtengenerierung Optimierung Plan-Übersetzung Ausführung

Joins 6 Interaktive oder Eingebettete Anfragen (Cobol, PL/1, C, Fortran) Die Anfragebearbeitung konzentriert sich auf das Extrahieren von Informationen ohne Daten zu verändern. Für Updates siehe den Vorlesungsabschnitt über Transaktionen und ACID-Semantik. Atomic Consistent Isolated Durable

Joins 7 Anfragebearbeitung: Eingabe sind Relationen und Mengen Alle Implementierungen von Anfrage-Algorithmen iterieren über den Elementen der Eingabemengen. Mengen sind als Sequenzen verwirklicht. Algorithmen: Physische Algebra Systemspezifisch vs. Logische Algebra Datenmodell

Joins 8 Hersteller A Hersteller B Datenmodell logische Algebra physische Algebra physische Algebra Beispiel: Hersteller A: Nested-Loops Join Hersteller B: Nested-Loops Join & Merge Join

Joins 9 Spezifische Algorithmen (mit Kostenfunktion) sind nur physischen Operatoren zugeordnet, nicht aber logischen. Ein Ausdruck der logische Algebra ist nicht direkt ausführbar. Er muss in einen Ausdruck der physischen Algebra übersetzt werden.

Joins 10 Beispiel: {A} {B} Merge-Join (Schnitt) sortieren sortieren Scannen Datei A Scannen Datei B

Joins 11 Abbildung von logischen Operatoren auf physische Operatoren Diese Abbildung ist schwierig und komplex, denn... Einige Operatoren der physischen Algebra können mehrere logische Operatoren verwirklichen. Beispiel: Implementierung von Joins (gängige Implementierungen ermöglichen bereits eine Projektion für die Ausgabemenge, jedoch ohne Duplikat- Entfernung diese Art der Projektion nennt man auch Delta-Projektion) Einige physische Operatoren verwirklichen nur einen Teil eines logischen Operators. Beispiel: Ein Algorithmus, der Duplikate eliminiert verwirklicht nur einen Teil des relationalen Projektions- Operators.

Joins 12 Einige physische Operatoren existieren in der logischen Algebra überhaupt nicht. Beispiel: Sortieren. Einige Eigenschaften, die für logische Operatoren gelten, gelten nicht (oder nur teilweise) für physische Operatoren. Beispiel:, : Symmetrie und Kommutativität gelten (bezogen auf den Kostenfaktor) nicht, z.b. für Implementierung durch Nested-Loops.

Joins 13 Tupel, Relationen, Mengen + Relationale Algebra Physisches Datenbanken- Design Anfrageoptimierung Datentypen, Dateien, Sätze, Bytefelder + Low-Level Operationen

Joins 14 Kartesisches Produkt AB CD n AB n CD (Datensätze) Strategie: Lade so viele Blöcke von AB wie möglich in den Hauptspeicher und lasse dabei Platz für einen Block von BC. AB CD m Hauptspeicher-Blöcke

Joins 15 n, n : Sätze. AB CD b, b : Sätze/Block. AB CD m : Anzahl der Blöcke im Hauptspeicher. Anzahl der Block-Zugriffe um AB zu lesen: nab b AB. CD muss n ( m ) AB Jedes Mal werden dazu n 1 b AB - mal gelesen werden. CD b CD Zugriffe benötigt. Anzahl der Block-Zugriffe: n b AB AB + n AB ( m 1) b AB n b CD CD = n b AB AB 1+ n CD ( m 1) bcd

Joins 16 Beispiel: n b AB AB = n = 10 000 = b = 5 m = 100 CD CD Anzahl der Zugriffe = 42.400. Bei 20 Block-Zugriffen pro Sekunde wird dieses kartesische Produkt ca. 35 Minuten benötigen. Wähle AB als die Relation, mit dem kleineren Quotienten n bab AB. Das heißt, die Relation, die in weniger Blocks passt.

Joins 17 IMPLEMENTIERUNG VON JOINS Gegeben sei folgende Abfrage: ( σ ( )) πa B= C D= 99 AB CD Nach den, in Teil 1 der Vorlesung behandelten, Verfahren kann man diesen relationalen Ausdruck zunächst so umformen: ( = ( AB = 99 ( CD) )) π σ σ A B C D Durch Ersetzen des kartesischen Produktes durch einen natürlichen Verbund ergibt sich folgende optimierte Abfrage: π A AB >< σ B= C D = 99 ( CD)

Joins 18 π A AB >< σ B= C D = 99 ( CD) Wie kann diese Abfrage implementiert werden? 1. ><, σ, π oder 2. σ, ><, π ist besser wenn CD: Index(D) dann ist σ d=99 (CD) schnell. sonst Scanne CD (einmal) mit n b CD CD Blockzugriffen { Menge von Tupeln aus CD mit D=99 }

Joins 19 Beispiel: n AB = n CD = 10.000 b AB = b CD = 5 m = 100 (Hauptspeicher) AB CB: 42.000 Blockzugriffe bei 20 Blocks/sec 35 Minuten Wenn aber die Selektion vorher ausgeführt wird: n b CD CD = 2.000 C 12 4 34 D 99 ( CD) σ D =99 nur dieser Teil ist von Interesse!

Joins 20 Die Menge von C-Werten wird verglichen mit einer Menge von B-Werten (AB) wenn # C-Werte klein (passt in den Hauptspeicher) AB hat einen Index(B) dann benötigt AB >< ( CD) σ 99 wenige Blockzugriffe. B = C D = wenn # C-Werte klein, kein Index dann Scanne AB (einmal) mit n b AB AB = 2.000 Blockzugriffen 2.000 + 2.000 = 4.000 3,5 Minuten vs. AB x CD = 42.400 35 Minuten Umformen der Abfrage!!

Joins 21 Bisherige Annahme: σ Ergebnis paßt in den Hauptspeicher Jetzt: AB>< CD B= C AB und CD passen nicht in den Hauptspeicher Implementierungsstrategien (Join) Nested-Loops Join Sort-Merge Join Hash Join

Joins 22 Generelle Strategien (physikalisch) Vorverarbeitung der Dateien z.b. - Sortieren, - Erzeugen von Indizes. Berechnung von Optionen vor der Ausführung z.b. AB BC n b AB AB vs. n b CD CD

Joins 23 Nested-Loops Join AB >< CD R >< S ( ) ( ) B= C r a θ s b äußere innere Für jedes Tupel der äußeren Relation werden alle Tupel der inneren Relation gelesen und verglichen. s S do { r R do { if r(a) θ s(b) then r s Speichern in Q } } -- Einfachste Methode -- Effizienz: Die innere Relation sollte die mit der größeren Kardinalität sein.

Joins 24 Nested Loops Nested Blocks Da Sätze immer nur in ganzen Blöcken gelesen werden können, liegt folgende Optimierung nahe: äußere innere Rocking der inneren Relation äußere innere

Joins 25 Performanz: ( m) On Anwendung: Unpassend für sehr große Relationen Gut für parallele Implementierung (Hardware Datenbankmaschinen)

Joins 26 Sort-Merge Join Schritt 1: Sortiere AB, Sortiere CD. Schritt 2: Vergleiche & Mische n b AB AB n + b CD CD AB>< CD B= C Falls B und C Schlüssel: read 1 st Tuple R read 1 st Tuple S r do { while s(c) < r(b) read next s S; if r(b) = s(c) then join r and s store in Q }

Joins 27 Falls die Join-Attribute keine Schlüssel sind, dann kann ein Wert mehr als einmal vorkommen, deshalb können mehrere Durchläufe der inneren Relation notwendig sein. R r(b) S s(c) r1 X X s1 r2 X X s2 X s3 Modifiziere den Algorithmus so, dass er den letzten Wert r(b) und den Punkt in S, an dem der letzte innere Loop begann, speichert. Immer wenn ein doppelter (mehrfacher) r(b)-wert erkannt wird, wird die Schleife an dem vorherigen Startpunkt in S neu begonnen.

Joins 28 Hauptvorteil: Die Anzahl der Vergleiche zwischen Tupeln wird reduziert. Performanz: Wenn die Relationen bereits sortiert vorliegen, ist der Algorithmus besser als Nested-Loop. Jede Relation wird nur einmal gelesen. Die Ausführungszeit wird durch Sortieren und Mischen beschränkt. Sortieren: On ( log n)

Joins 29 HASHED JOIN METHODE Idee: Versuche die Tupel der ersten Relation zu isolieren, die zu einem gegebenen Tupel der zweiten Relation unter der Joinbedingung passen.

Joins 30 SIMPLE HASH JOIN Erste Relation: Die Werte der Join-Attribute der ersten Relation werden mittels einer Hashfunktion gehashed. h(v) Hashtabelle Inhalt: 1. Tupel, oder 2. TID, Schlüssel Buckets Buckets

Joins 31 2-te Relation: Für jedes Tupel der zweiten Relation werden die Join- Attribute mit der selben Hashfunktion gehashed. Wenn die Werte auf ein nicht leeres Bucket gehashed werden, dann werden die entsprechenden Tupel miteinander verglichen.

Joins 32 Simple Hash R ( ) θ sb ( ) ra >< S Algorithmus: s S do { Hashe über den Join-Attributen s(b); stelle die Tupel in die Hashtabelle entsprechend den gehashten Werten; } r R do { Hashe über den Join-Attributen r(a); if r auf ein nicht-leeres Bucket hashed then if r θ s then speichere r s in Q }

Joins 33 Die Hashtabelle wird üblicherweise für die kleinere der beiden Relationen angelegt. Performanz: Hash-basierte Joins sind die effektivsten Join-Techniken. Komplexität: ( + m) On da beide Relationen nur einmal gelesen werden. Die Geschwindigkeit hängt von der Hashfunktion ab. Hash-Kollisionen vermindern die Performanz! Jedes Tupel, dass auf ein nicht-leeres Bucket hashed, muss überprüft werden, ob es der Join-Bedingung genügt. Falls die Join-Bedingung θ = ist, ist die Implementierung schwierig! Die Eliminierung von Duplikaten in der Ergebnismenge ist schwierig.

Joins 34 HASH-PARTITIONED JOINS Idee: Benutzen eines Teile und Herrsche -Ansatzes. 1. Eine Hashfunktion (Splitfunktion) partitioniert die Tupel beider Relationen in eine feste Anzahl disjunkter Mengen. 2. Tupel hashen in eine Menge, falls der gehashte Wert ihrer Join-Attribute in den Bereich der Wertemenge dieser Menge fällt. 3. Tupel in der ersten Menge für die Relation R können nur mit Tupeln der ersten Menge der Relation S zusammenpassen.

Joins 35 R a S b 2 3 a = b 2 8 3 8 h(a) { }, { }, { }, { }, h(b) { }, n = m { }, Benutze einen Simple-Hash Join für die Tupel innerhalb der Partitionen.

Joins 36 Hauptvorteil: Die Anzahl der Tupel, die während des Join-Prozesses miteinander verglichen werden müssen, wird reduziert (Join Load). Die Partitionen können so klein gewählt werden, dass die Hashtabelle für die Tupel der ersten Relation in den Hauptspeicher passt. Implementierungs-Strategien: GRACE Hash Join (nur dieser wird im Folgenden vorgestellt) Hybrid Hash Join Hashed Loops Join...

Joins 37 GRACE HASH JOIN Partitionieren Vergleichen Partitionieren: Teilen von R und S in eine gleiche Anzahl von disjunkten Mengen. Eins-zu-eins Beziehung zwischen den Mengen von R und S. Die Mengen von R und S befinden sich auf verschiedenen Festplatten (oder Rechnern).

Joins 38 Vergleichen: Der Vergleich wird für jede Partition getrennt durchgeführt Die Ergebnisse aller Vergleiche werden zusammengeführt.

Joins 39 Algorithmus: for each Tupel r do { Hashe über den Join-Attributen r(a) i ; Stelle das Tupel in den Output-Buffer R[i] } ; Flushe die Output-Buffer ; for each Tupel s do { Hashe über den Join-Attributen s(b) i ; Stelle das Tupel in den Output-Buffer S[i] } ; Flushe die Output-Buffer ; for i = 1, 2,..., N do { for R[i] do { Erzeuge eine Hashtabelle für die Tupel in R[i]; Lese die Hashtabelle in den Hauptspeicher } ; for S[i] do { Hashe über den Join-Attributen s(b) ; if Übereinstimmung in R[i] gefunden then { Konkateniere die beiden Tupel ; Speichere das Ergebnis in Q } } }

Joins 40 Partitionierung und Joinen sind beim GRACE Hash Join zwei getrennte Phasen. Performanz: (( + ) / ) O n m K R und S sind in K Speicherblöcken gespeichert und es stehen (2 * K) Prozessoren zur Verfügung. Multiprozessorsystem ist wünschenswert! Die Vergleiche auf den disjunkten Partitionen können sehr gut parallelisiert ausgeführt werden.

Joins 41 SELECTIVITY FACTOR Der Selectivity Factor (Join Selection Factor) ist die Anzahl der Tupel die gejoint werden, oder die Anzahl der Tupel des kartesischen Produktes, falls keine Join-Bedingung vorhanden ist. klein Nested Loop schlecht Hashed Join besser groß Nested Loop Hashed Join oder besser! Partitioned Hash Join besser Frage: Wie kann der Selectivity Factor bestimmt werden?

Joins 42 Übersicht Nested-Loops Join O(n x m) o mit Nested-Blocks o mit Roching Sort-Merge Join O(n log n) Hash Join o Simple Hash Join O(n + m) o Hash-Partitioned Join Grace Hash Join O((n + m) / K) K Speicherblöcken und 2K Prozessoren

Joins 43 Literatur: Query Evaluation Techniques for Large Databases S. Graefe ACM Computing Survey, Vol. 25, No. 2, Juni 1993 Join Processing in Relational Databases P. Mishra, M. H. Eich ACM Computing Survey, Vol. 24, No. 1, März 1992