Auswerten des Abfrageplans

Sie können Abfragepläne verwenden, um Kandidaten für die Optimierung des Verteilungsstils zu identifizieren.

Nachdem Sie Ihre anfänglichen Designentscheidungen getroffen haben, erstellen Sie Ihre Tabellen, laden Daten in sie und testen sie. Verwenden Sie einen Testdatensatz, der so nahe an den realen Daten wie möglich ist. Messen Sie die Ladezeiten, um sie als Ausgangspunkt für Vergleiche verwenden zu können.

Werten Sie Abfragen aus, die repräsentativ für die aufwändigsten Abfragen sind, die Sie voraussichtlich ausführen werden, insbesondere Abfragen, die Joins und Aggregationen verwenden. Vergleichen Sie die Laufzeiten für verschiedene Designoptionen. Wenn Sie die Laufzeiten vergleichen, sollten Sie die erste Ausführung der Abfrage nicht berücksichtigen, da die erste Laufzeit die Kompilierungszeit enthält.

DS_ DIST _ NONE und DS_ _ DIST ALL _ NONE sind gut. Sie zeigen an, dass für diesen Schritt keine Verteilung erforderlich war, da alle Joins zusammen platziert waren.

DS_ DIST _ INNER bedeutet, dass der Schritt wahrscheinlich relativ teuer ist, weil die innere Tabelle auf die Knoten umverteilt wird. DS_ DIST _ INNER gibt an, dass die äußere Tabelle bereits ordnungsgemäß auf dem Join-Schlüssel verteilt ist. Setzen Sie den Verteilungsschlüssel der inneren Tabelle auf den Join-Schlüssel, um diesen in DS_ _ DIST zu konvertieren. NONE In einigen Fällen ist eine Verteilung der inneren Tabelle auf den Join-Schlüssel nicht möglich, da die äußere Tabelle nicht auf den Join-Schlüssel verteilt ist. Wenn dies der Fall ist, prüfen Sie, ob die ALL Verteilung für die innere Tabelle verwendet werden soll. Wenn die Tabelle nicht häufig oder umfassend aktualisiert wird und sie groß genug ist, um hohe Umverteilungskosten zu verursachen, ändern Sie den Verteilungsstil auf ALL und testen Sie erneut. ALLDie Verteilung führt zu längeren Ladezeiten. Wenn Sie den Test erneut durchführen, sollten Sie die Ladezeit in Ihre Bewertungsfaktoren einbeziehen.

DS_ _ DIST ALL _ INNER ist nicht gut. Das bedeutet, dass die gesamte innere Tabelle auf ein einzelnes Segment umverteilt wird, weil die äußere Tabelle verwendet DISTSTYLEALL, sodass sich auf jedem Knoten eine Kopie der gesamten äußeren Tabelle befindet. Dies führt zu einer ineffizienten seriellen Laufzeit des Joins auf einem einzelnen Knoten, anstatt die Vorteile einer parallelen Laufzeit unter Verwendung aller Knoten zu nutzen. DISTSTYLEALLsoll nur für die innere Join-Tabelle verwendet werden. Geben Sie stattdessen einen Verteilungsschlüssel an oder verwenden Sie für die äußere Tabelle die EVEN-Verteilung.

DS_ BCAST _ INNER und DS_ DIST _ BOTH sind nicht gut. In der Regel erfolgen diese Umverteilungen, da für die Tabellen kein Join anhand ihrer Verteilungsschlüssel ausgeführt wurde. Wenn die Faktentabelle noch nicht über einen Verteilungsschlüssel verfügt, geben Sie für beide Tabellen die Join-Spalte als Verteilungsschlüssel an. Wenn die Faktentabelle bereits über einen Verteilungsschlüssel anhand einer anderen Spalte verfügt, überprüfen Sie, ob eine Änderung des Verteilungsschlüssels, damit dieser Join zusammen platziert werden kann, die Leistung insgesamt verbessert. Wenn das Ändern des Verteilungsschlüssels der äußeren Tabelle keine optimale Wahl ist, können Sie eine Kollokation erreichen, indem Sie DISTSTYLE ALL für die innere Tabelle angeben.

Das folgende Beispiel zeigt einen Teil eines Abfrageplans mit den Labels DS_ BCAST _ INNER und DS_ _DIST. NONE

->  XN Hash Join DS_BCAST_INNER  (cost=112.50..3272334142.59 rows=170771 width=84)
        Hash Cond: ("outer".venueid = "inner".venueid)
        ->  XN Hash Join DS_BCAST_INNER  (cost=109.98..3167290276.71 rows=172456 width=47)
              Hash Cond: ("outer".eventid = "inner".eventid)
              ->  XN Merge Join DS_DIST_NONE  (cost=0.00..6286.47 rows=172456 width=30)
                    Merge Cond: ("outer".listid = "inner".listid)
                    ->  XN Seq Scan on listing  (cost=0.00..1924.97 rows=192497 width=14)
                    ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=24)

Nachdem Sie die zu verwendenden Dimensionstabellen geändert haben DISTSTYLEALL, zeigt der Abfrageplan für dieselbe Abfrage DS_ _ DIST _ anstelle von ALL DS_ _ NONE an. BCAST INNER Es gibt darüber hinaus eine wesentliche Änderung bei den relativen Kosten für die Join-Schritte. Die Gesamtkosten sind 14142.59 verglichen mit 3272334142.59 in der vorherigen Abfrage.

->  XN Hash Join DS_DIST_ALL_NONE  (cost=112.50..14142.59 rows=170771 width=84)
        Hash Cond: ("outer".venueid = "inner".venueid)
        ->  XN Hash Join DS_DIST_ALL_NONE  (cost=109.98..10276.71 rows=172456 width=47)
              Hash Cond: ("outer".eventid = "inner".eventid)
              ->  XN Merge Join DS_DIST_NONE  (cost=0.00..6286.47 rows=172456 width=30)
                    Merge Cond: ("outer".listid = "inner".listid)
                    ->  XN Seq Scan on listing  (cost=0.00..1924.97 rows=192497 width=14)
                    ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=24)