Redshiftとソートキー

はじめに

Redshiftのソートキーはすっごく重要です。

1. 最速JOINはマージJOIN

2. Group byでもソートキーが使用される

3. WHEREでレコードを絞り込むときにも有効

どの場合もソートキーの項目順をちゃんと合わせてないといけません。特に夜間バッチでよく使われる全件突合＋全件出力ではマージJOINを目指します。

ソートキーの利用

マージJOIN

条件

JOINのキーに分散キー、ソートキーが使用されているソートキーの順番が同じ

これは効き目がめっちゃ大きいのでぜひとも狙いたいところ。

Group by

条件

集計キーに分散キー、ソートキーが使用されているソートキーの上位から歯抜けにならずに集計キーに使ってること

マージJOINと同じ条件ですね。これもソート済の特性をうまく利用されるので集計元テーブルのソートキーはちょっと注目ソートキーははWindow関数のグルーピングでも使用されます。

Where

条件

絞り込みの条件に先頭のソートキーが含まれてること。２つのソートキーが設定されている場合に、効率的に検索する場合にはwhereで先頭に設定されているソートキーが指定されていることが必須。そうしないとゾーンマップ（データブロック毎の最大最小値データ）が使用できない。

先頭のソートキーがWhereに含まれてると、絞り込みが激速です。絞り込みされる処理ではその後のJOINがハッシュJOINになっても気にしない。

ソートについて

ソート処理

ソートキーを使うためにはソート処理が動きますが、ソート自体は負荷が高い処理なので、リソースも多く使います。

ソートのディスク容量

ソートするためには一時領域が必要なので、メモリに乗らないような大きなデータをソートするとソート用の領域としてディスクが使用されます。どでかいデータを一発INSERTする時にディスクの使用率が一時的に上がるのは（たぶん）そのためです。

Disk増加の回避策は

やったことないけど　第一ソートキーの条件でテーブルを複数に分割。　そのテーブルをUNIONのVIEWで繋いで使用する。　　ゾーンマップはうまく使われるはずだけど、マージJOINに持って言ってくれるかは未知数

おわりに

一時的なディスク容量って、結構使うから嫌ですよね。どうしてもディスクが跳ねるときは第一ソートキーのmodなどで参照データを均等数に絞り込んで、同じSQLを２〜３回に分けて流す方が早かったりする。なんで２〜３回かって言うと、それで動かないようだと根本的な処理構成／データ構造を見直したほうが良いと思う。当然だけど、分散キーで分けちゃだめ。

以上