Was bedeutet es, mehrere Sortierschlüsselspalten zu haben?

Question

Redshift kann mehrere Spalten als SORTKEY Spalten bezeichnen, aber die meisten der Best-Practices-Dokumentation geschrieben werden, als ob es nur eine einzige SORTKEY war.

Wenn ich eine Tabelle mit SORTKEY (COL1, COL2) schaffen, bedeutet das, dass alle Spalten von COL1 sortiert gespeichert werden, dann COL2? Oder vielleicht, da es ein säulenartiger Speicher ist, wird jede Spalte in einer anderen Reihenfolge gespeichert? I.e. COL1 in COL1-Reihenfolge, COL2 in COL2-Reihenfolge und die anderen Spalten ungeordnet?

Meine Situation ist, dass ich eine Tabelle mit (unter anderem) eine type_id und einen Zeitstempel-Spalte haben. Die Daten werden grob in der Reihenfolge der Zeitstempel empfangen. Die meisten Abfragen werden mit type_id und timestamp verknüpft/eingeschränkt. Normalerweise sind die type_id-Klauseln spezifischer, was bedeutet, dass ein viel größerer Prozentsatz von Zeilen durch Betrachten der type_id-Klausel ausgeschlossen werden kann, als durch Betrachten der timestamp-Klausel. type_id ist der DISTKEY aus diesem Grund. Ich versuche, die Vor- und Nachteile von SORTKEY (type_id), SORTKEY (stamp), SORTKEY (type_id,stamp), SORTKEY (stamp,type_id) zu verstehen.

Danke.

Answer 1

Wenn Sie SORTKEY(COL1, COL2) deklarieren, werden alle Spalten nach COL1 und dann COL2 sortiert, als wäre ORDER BY (COL1, COL2) erledigt.

Wenn Sie SORTKEY verwenden eine zu beschleunigen JOIN, AFAIU es spielt keine Rolle, solange Sie die gleiche SORTKEY auf den Tischen verwenden, die verbunden werden, weil das, was ein Merge ist passiert verbinden.

Wenn COL1 sehr selektiv ist wie Ihre type_id, bedeutet dies, dass es nur eine kleine Anzahl von Zeilen gibt, die dieselbe type_id haben. Daher können Sie, obwohl Sie SORTKEY eine weitere Spalte hinzufügen können, das Dienstprogramm einschränken, da der Großteil der Zeileneliminierung bereits erfolgt ist.

Wenn COL1 ist nicht sehr selektiv wie Ihr stamp (die übrigens ein bisschen komisch ist,? Ich erwartet hätte es als type_id selektiver sein Anyways ..), bedeutet dies, dass die Filterung durch stamp wird nicht so viel beseitigen Reihen. Daher ist es sinnvoller, einen zweiten Sortierschlüssel zu deklarieren. Dies ist jedoch weniger effizient als andersherum, da das frühere Löschen von Zeilen billiger wäre. Wenn Sie manchmal nach stamp filtern, aber nicht nach type_id, kann es sinnvoll sein, dies jedoch zu tun.

Answer 2

Wir verwenden auch Redshift und wir haben ungefähr 2 Milliarden Datensätze (+20 Millionen jeden Tag) und ich muss sagen, je weniger selektiv der sort_key ist, desto mehr sollte er in der sort_key-Liste sein.

In unserem Fall (und bitte zu analysieren beraten, wie Sie Ihre eigenen Daten verwenden/abfragen) wir Zeitstempel als erste sort_key verwendet. Das Problem dabei ist, dass wir sogar innerhalb von 1 Sekunde ungefähr 200 Zeilen aufzeichnen, was dazu führt, dass unsere 1 MB Blöcke nur ein paar Sekunden enthalten, und jede Art von Daten in diesem einzelnen Block. Das heißt, obwohl Timestamp sehr selektiv ist, nachdem wir nicht wirklich weiter filtern können, da wir alle Arten von Daten in jedem Block haben.

Vor kurzem haben wir die Reihenfolge der sort_keys umgekehrt. Der erste hat ungefähr 15 verschiedene Werte, der zweite hat ungefähr 30 usw., und der Zeitstempel ist jetzt der letzte, aber immer noch wird ein Block in Sekunden gemessen.

Dies ergibt die folgende (da wir die ersten beiden sort_keys als Filter sehr häufig verwenden): Alte Lösung: Ein Jahr der Daten, einen Monat auszuwählen, fällt es 91% der Blöcke, aber nachdem es zu öffnen, hat alle von ihnen, obwohl wir weiter filtern wollen.

Die neue Lösung löscht ungefähr 14/15 der Blöcke im ersten Schritt, unabhängig vom Datumsbereich, dann etwa 95% der verbleibenden und der Zeitstempel lässt immer noch 91% der verbleibenden Blöcke fallen.

Wir haben es gründlich mit zwei, 800 Millionen Datensätze Tabellen getestet, die die gleichen waren, mit Ausnahme der Reihenfolge der Sortierschlüssel. Je höher die Zeitspanne in der Where-Klausel war, desto bessere Ergebnisse erzielten wir. Im Fall von Joins wurde es sogar noch wichtiger.

Also mein Vorschlag ist, wissen Sie Ihre Datenbank und welche Art von Abfragen Sie häufig ausführen, weil die selektivste Spalte möglicherweise nicht die beste erste sort_key sein. Genau wie Enno Shioji sagte, hängt alles davon ab, was Sie filtern.

Answer 3

ich den Auftrag für sort_key sagen sollte

1. sein betrachten diejenigen in dist, Filter und kommen zuerst
2. die in Filter betrachten, verbinden
3. die in Filter betrachten
4. diejenigen betrachten in join
5. betrachten diejenigen in der Gruppe von, Reihenfolge von (einschließlich Fensterfunktion)

die allgemeine Regel: niedrigere Kardinalität zuerst gesetzt, wenn das gleiche Niveau.