top of page
検索

Redshiftとソートキー

a k

はじめに

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

  1. 最速JOINはマージJOIN

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

  3. 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回かって言うと、それで動かないようだと根本的な処理構成/データ構造を見直したほうが良いと思う。当然だけど、分散キーで分けちゃだめ。


以上


閲覧数:253回0件のコメント

最新記事

すべて表示

Lambda SnapStart(Python)使ってみた

Python および .NET 関数向けの AWS Lambda SnapStart の一般提供を開始 https://aws.amazon.com/jp/blogs/news/aws-lambda-snapstart-for-python-and-net-function...

Amazon Redshiftのクエリコンパイル問題に立ち向かう

はじめに 前回、Amazon Redshiftがたまに遅くなる事象について記事にしました。 対策については触れていなかったので今回は検討した案をいくつか書き記したいと思います。 問題点 Redshiftのバージョンアップによってクエリコンパイルが発生し、バージョンアップ後の...

Comentarios


  • Facebook

©Optarc,llc.

bottom of page