Redshift Query nimmt zu viel Zeit in Anspruch

Question

In Redshift dauert die Ausführung der Abfragen zu lange. Einige Abfragen laufen weiter oder werden nach einiger Zeit abgebrochen.

Ich habe sehr begrenzte Kenntnisse von Redshift und es wird schwierig, den Abfrageplan zu verstehen, um die Abfrage zu optimieren.

Teilen einer der von uns ausgeführten Abfragen zusammen mit dem Abfrageplan. Die Abfrage dauert 20 Sekunden zur Ausführung.

Abfrage

SELECT 
    date_trunc('day', 
    ti) as date, 
    count(distinct deviceID) AS COUNT  
FROM 
    live_events 
WHERE 
    brandID = 3927 
    AND ti >= '2017-08-02T00:00:00+00:00' 
    AND ti <= '2017-09-02T00:00:00+00:00' 
GROUP BY 
    1 

Primärschlüssel
brandid

Verschachtelte Sortieren Keys
wir folgende Spalten als verschachtelter Sortierschlüssel festgelegt haben -
brandid, ti, event_name

QUERY PLAN

Answer 1

Sie haben 126 Millionen Zeilen in dieser Tabelle. Es dauert mehr als eine Sekunde auf einem einzelnen Knoten.

Hier einige Möglichkeiten, wie Sie die Leistung verbessern könnte:

Weitere Knoten

Verbreitung von Daten über mehrere Knoten mehr Parallelisierung erlaubt. Jeder Knoten fügt zusätzliche Verarbeitung und Speicherung hinzu. Auch wenn Ihr Datenvolumen nur einen Knoten rechtfertigt, fügen Sie weitere Knoten hinzu, wenn Sie mehr Leistung wünschen.

SORTKEY

Für die richtige Art der Abfrage kann die SORTKEY der beste Weg Abfragegeschwindigkeit zu verbessern. Sortieren von Daten auf der Festplatte ermöglicht Redshift zu überspringt Blöcke, die es weiß, enthält keine relevanten Daten.

Zum Beispiel hat Ihre Abfrage WHERE brandID = 3927, also brandID als SORTKEY würde dies extrem effizient machen, weil sehr wenige Festplattenblöcke Daten für eine Marke enthalten würde.

Interleaved Sortierung ist selten die beste Sortiermethode zu verwenden, weil es weniger effizient als ein einzelner oder zusammengesetzter Sortierschlüssel ist und eine lange Zeit dauert, bis VACUUM.Wenn die von Ihnen angezeigte Abfrage typisch für die Art der ausgeführten Abfragen ist, verwenden Sie einen zusammengesetzten Sortierschlüssel von brandId, ti oder . Es wird viel effizienter sein.

SORTKEYs sind normalerweise eine Datumsspalte, da sie oft in einer WHERE-Klausel zu finden sind, und die Tabelle wird automatisch sortiert, wenn Daten immer in zeitlicher Reihenfolge angehängt werden.

Die Interleaved Sort würde Redshift veranlassen, viel mehr Festplattenblöcke zu lesen, um Ihre Daten zu finden, wodurch die Abfragezeit erheblich verlängert wird.

DISTKEY

Die DISTKEY typischerweise auf dem Gebiet festgelegt werden sollte, dass die meisten in einem auf dem Tisch JOIN-Anweisung verwendet wird. Dies liegt daran, dass Daten, die sich auf den gleichen DISTKEY-Wert beziehen, auf demselben Slice gespeichert sind. Dies wird keinen so großen Einfluss auf einen einzelnen Knoten-Cluster haben, aber es lohnt sich immer noch richtig zu werden.

Auch hier haben Sie nur einen Abfragetyp angezeigt, daher ist es schwierig, einen DISTKEY zu empfehlen. Basierend auf dieser Abfrage würde ich DISTKEY EVEN empfehlen, so dass alle Slices an der Abfrage teilnehmen. (Es ist auch das Standard-DISTKEY, wenn kein spezifisches DISTKEY ausgewählt ist.) Alternativ kann DISTKEY auf ein nicht gezeigtes Feld gesetzt werden - aber sicherlich nicht brandId als DISTKEY verwenden, ansonsten wird nur ein Slice an der Abfrage teilnehmen.

VACUUM

VACUUM regelmäßig Ihre Tabellen so, dass die Daten in SORTKEY Reihenfolge gespeichert und gelöschte Daten aus dem Speicher entfernt werden.

Experiment!

Die optimalen Einstellungen hängen von Ihren Daten und den Abfragen ab, die Sie normalerweise ausführen. Führen Sie einige Tests durch, um SORTKEY- und DISTKEY-Werte zu vergleichen, und wählen Sie die Einstellungen, die am besten abschneiden. Testen Sie dann innerhalb von 3 Monaten erneut, ob Ihre Abfragen oder Daten sich so geändert haben, dass andere Einstellungen effizienter werden.