6.5 Bearbeitung von Join-Anfragen

6.5.2 Semi-Join-Strategien

Der Overhead des Fetch-As-Needed-Ansatzes kann jedoch leicht reduziert werden, indem nicht für jeden Satz einer Relation die Verbundpartner einzeln angefordert werden, sondern alle auf einmal. Dies ist die Idee, die von Semi-Join-Strategien genutzt wird. Hierzu werden sämtliche Verbundattributwerte der ersten Relation in einer Nachricht an den Knoten der zweiten Relation übertragen. Daraufhin können alle Verbundpartner in einer Nachricht an den ersten Knoten zurückgesendet werden, wo dann die Join-Bildung erfolgt.

Diese Vorgehensweise entspricht der Anwendung eines Semi-Joins. Denn es gilt:

R S R (S R) R (S V (R))

wobei V dem Verbundattribut entspricht (bzw. der Menge der Verbundattribute). Die Join-Berechnung R S läuft demnach in folgenden Schritten ab:

1. In KR: Bestimmung der Verbundattributwerte V (R) und Übertragung an KS

2. In KS: Bestimmung von Z = (S V (R)) = (S R) und Übertragung an KR

3. In KR: Bestimmung von R Z = R S.

Aufgrund folgender Äquivalenzen

R S R (S R)

R S (R S) S

R S (R S) (S R)

gibt es bei zwei Relationen jedoch insgesamt (wenigstens) drei Semi-Join-Strategien. Die zweite Strategie entspricht der ersten, wobei die Rollen von R und S vertauscht sind (Join-Bildung am S-Knoten). Die dritte Strategie enthält zwei Semi-Joins und kann z.B. sinnvoll sein, wenn das Gesamtergebnis an einem dritten Knoten berechnet werden soll. In letzterem Fall werden insgesamt fünf Teilschritte notwendig:

1a. In KR: Bestimmung der Verbundattributwerte V (R) und Übertragung an KS

1b. In KS: Bestimmung der Verbundattributwerte V (S) und Übertragung an KR

2a. In KS: Bestimmung von Z1 = (S V (R)) = (S R) und Übertragung an K

2b. In KR: Bestimmung von Z2 = (R V (S)) = (R S) und Übertragung an K

3. In K: Bestimmung von Z1 Z2 = R S.

Dabei entspricht K dem Knoten, an dem das Gesamtergebnis bestimmt wird. Zu beachten ist, daß die Schritte 1a und 1b sowie 2a und 2b jeweils parallel ausgeführt werden können. Die Nachrichtenanzahl hat sich von zwei auf vier erhöht. Wird auf die Parallelbearbeitung der beiden Relationen verzichtet, läßt sich der Übertragungsumfang reduzieren, indem Knoten KS nur die Join-Attributwerte an KR (oder umgekehrt) zurückliefert, die tatsächlich im Verbundergebnis erscheinen (s. Aufgabe 6-8:).

Beispiel 6-10

Die drei Semi-Join-Strategien sollen auf die Beispielrelationen in Abb. 6-12 angewendet werden. Wir veranschaulichen die Einzelschritte für den komplizierteren Fall mit zwei parallelen Semi-Joins. Die fünf Schritte liefern folgende Zwischenergebnisse:

1a. In KR: Bestimmung von B (R)

1b. In KS: Bestimmung von B (S)

2a. In KS: Bestimmung von Z1 = (S B (R))

2b. In KR: Bestimmung von Z2 = (R B (S))

3. In K: Bestimmung von Z1 Z2 = R S

.

Der Nachrichtenumfang dieser Strategie beträgt #AW = 19. Für die einfachen Semi-Join-Strategien betragen die Kosten #AW=11 bzw. #AW=8 für die Join-Berechnung an KR bzw. KS. Diese Kosten erhöhen sich jedoch um 8 Attributwerte, falls das Ergebnis an einen anderen Knoten transferiert werden muß.
Der Vergleich mit den einfachen Join-Strategien (Beispiel 6-8) zeigt, daß die Semi-Join-Methoden den Fetch-As-Needed-Ansätzen nicht nur in der Nachrichtenanzahl, sondern auch im Übertragungsumfang überlegen sind. Gegenüber Ship-Whole sind nur wenige zusätzliche Nachrichten erforderlich, jedoch kann das Übertragungsvolumen deutlich reduziert werden (8 vs. 14 AW).

Echte Zusatzkosten der Semi-Join-Strategien im Vergleich zum Transfer ganzer Relationen (Ship Whole) liegen in den Übertragungskosten für die Verbundattributwerte. Damit Semi-Join-Strategien insgesamt besser abschneiden, sind diese Kosten durch eine entsprechende Reduzierung bei der Rücklieferung der Verbundpartner zu amortisieren. Die Join-Selektivität muß also ausreichend hoch sein, so daß die Menge der angeforderten Verbundpartner (wesentlich) kleiner ist als die ganze Relation. Dies ist häufig der Fall, gilt jedoch z.B. nicht für viele hierarchische Joins, wenn nahezu jeder Primärschlüsselwert auch als Fremdschlüssel vorkommt. Die lokalen Join-Kosten können bei Semi-Join-Ansätzen auch höher liegen als beim Transfer ganzer Relationen, da mehr Teiloperationen auszuführen sind, wenngleich mit kleineren Operanden. Dennoch ist es z.B. erforderlich, einzelne Relationen mehrfach zu referenzieren (z.B. zunächst zur Bestimmung der Verbundattributwerte und später zur eigentlichen Join-Berechnung), was hohe E/A-Kosten verursachen kann.