はじめに
Redshiftのソートキーはすっごく重要です。
最速JOINはマージJOIN
Group byでもソートキーが使用される
WHEREでレコードを絞り込むときにも有効
どの場合もソートキーの項目順をちゃんと合わせてないといけません。特に夜間バッチでよく使われる全件突合+全件出力ではマージJOINを目指します。
ソートキーの利用
マージJOIN
条件
JOINのキーに分散キー、ソートキーが使用されているソートキーの順番が同じ
これは効き目がめっちゃ大きいのでぜひとも狙いたいところ。
Group by
条件
集計キーに分散キー、ソートキーが使用されているソートキーの上位から歯抜けにならずに集計キーに使ってること
マージJOINと同じ条件ですね。これもソート済の特性をうまく利用されるので集計元テーブルのソートキーはちょっと注目ソートキーははWindow関数のグルーピングでも使用されます。
Where
条件
絞り込みの条件に先頭のソートキーが含まれてること。2つのソートキーが設定されている場合に、効率的に検索する場合にはwhereで先頭に設定されているソートキーが指定されていることが必須。そうしないとゾーンマップ(データブロック毎の最大最小値データ)が使用できない。
先頭のソートキーがWhereに含まれてると、絞り込みが激速です。絞り込みされる処理ではその後のJOINがハッシュJOINになっても気にしない。
ソートについて
ソート処理
ソートキーを使うためにはソート処理が動きますが、ソート自体は負荷が高い処理なので、リソースも多く使います。
ソートのディスク容量
ソートするためには一時領域が必要なので、メモリに乗らないような大きなデータをソートするとソート用の領域としてディスクが使用されます。どでかいデータを一発INSERTする時にディスクの使用率が一時的に上がるのは(たぶん)そのためです。
Disk増加の回避策は
やったことないけど 第一ソートキーの条件でテーブルを複数に分割。 そのテーブルをUNIONのVIEWで繋いで使用する。 ゾーンマップはうまく使われるはずだけど、マージJOINに持って言ってくれるかは未知数
おわりに
一時的なディスク容量って、結構使うから嫌ですよね。どうしてもディスクが跳ねるときは第一ソートキーのmodなどで参照データを均等数に絞り込んで、同じSQLを2〜3回に分けて流す方が早かったりする。なんで2〜3回かって言うと、それで動かないようだと根本的な処理構成/データ構造を見直したほうが良いと思う。当然だけど、分散キーで分けちゃだめ。
以上
Comentarios