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

Es ist keine Umverteilung erforderlich, da korrespondierende Slices auf den Datenverarbeitungsknoten zusammen platziert werden. In der Regel gibt es nur einen DS_DIST_NONE-Schritt, den Join zwischen der Faktentabelle und einer einzelnen Dimensionstabelle.

DS_DIST_ALL_NONE

Es ist keine Umverteilung erforderlich, da die innere Join-Tabelle bereits DISTSTYLE ALL verwendet hat. Die gesamte Tabelle befindet sich auf jedem Knoten.

DS_DIST_INNER

Die innere Tabelle wird umverteilt.

DS_DIST_OUTER

Die äußere Tabelle wird umverteilt.

DS_BCAST_INNER

Eine Kopie der gesamten inneren Tabelle wird an alle Verarbeitungsknoten gesendet.

DS_DIST_ALL_INNER

Die gesamte innere Tabelle wird an eine einzige Slice umverteilt wurde, weil die äußere Tabelle DISTSTYLE ALL verwendet.

DS_DIST_BOTH

Beide Tabellen werden umverteilt.

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 hohe Kosten verursacht, da die innere Tabelle an die Knoten umverteilt wird. DS_DIST_INNER zeigt an, dass die äußere Tabelle bereits korrekt anhand des Join-Schlüssels verteilt wurde. Legen Sie den Verteilungsschlüssel der inneren Tabelle auf den Join-Schlüssel fest, um dies in DS_DIST_NONE zu konvertieren. 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 groß genug ist, um zu hohen Umverteilungskosten zu führen, ändern Sie den Verteilungsschlüssel in ALL und führen den Test erneut aus. Die ALL-Verteilung verursacht höhere Ladezeiten. Berücksichtigen Sie daher die Ladezeit bei Ihrer Auswertung, wenn Sie den Test erneut ausführen.

DS_DIST_ALL_INNER ist nicht gut. Dies bedeutet, dass die gesamte innere Tabelle an einen einzelnen Slice umverteilt wird, da die äußere Tabelle DISTSTYLE ALL verwendet, 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. DISTSTYLE ALL ist nur für die Verwendung für die innere Join-Tabelle vorgesehen. 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 die Änderung des Verteilungsschlüssels der äußeren Tabelle keine optimale Wahl darstellt, können Sie eine gemeinsame Platzierung erzielen, indem Sie für die innere Tabelle DISTSTYLE ALL angeben.

Im folgenden Beispiel wird ein Teil eines Abfrageplans mit den Bezeichnungen DS_BCAST_INNER und DS_DIST_NONE gezeigt.

->  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)

Nach der Änderung des Verteilungsstils der Dimensionstabellen in DISTSTYLE ALL zeigt der Abfrageplan für dieselbe Abfrage DS_DIST_ALL_NONE anstelle von DS_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)