Redshiftのソートキー
前回の記事の続きでRedShiftのチューニング(ソートキー)を定義します。今回は結論はなしで、ベンチマークを残します。
前提
- RedShift
- PostgreSql
ソートキー
RedShiftでは、ソートキーを元に並び替えてデータをディスクに格納します。
最新のデータが最も頻繁にクエリ処理される場合は、タイムスタンプ列をソートキーの主要な列として指定します。 クエリは時間範囲外のブロック全体をスキップできるので、効率性が高まります。
1 つの列に対して範囲フィルタリングまたは等価性フィルタリングを頻繁に実行する場合は、その列をソートキーとして指定します。 Amazon Redshift は、各ブロックに格納された列の最小値と最大値を追跡し、述語範囲に当てはまらないブロックをスキップできるので、その列のブロック全体のデータを読み込む必要がなくなります。
テーブルを頻繁に結合する場合は、結合列をソートキーと分散キーの両方として指定します。 これにより、クエリオプティマイザは、より時間のかかるハッシュ結合ではなくソートマージ結合を選択できるようになります。データが結合キーですでにソートされているので、クエリオプティマイザはソートマージ結合のソートフェーズをバイパスできます。
ベンチマーク
複合ソートキーの指定ありで、copyコマンドの実行時間とサイズを検証してみた。
ファクト１つに対して、ディメンションが2つという仮定です。
copyコマンド(ソートキー指定なし)
INFO: Load into table 'table_a' completed, 28000000 record(s) loaded successfully. Time: 80379.260 ms INFO: Load into table 'table_b' completed, 1400 record(s) loaded successfully. Time: 3378.901 ms INFO: Load into table 'table_c' completed, 178 record(s) loaded successfully. Time: 3766.339 ms
copyコマンド(ソートキー指定あり)
INFO: Load into table 'table_a' completed, 28000000 record(s) loaded successfully. Time: 138134.710 ms INFO: Load into table 'table_b' completed, 1400 record(s) loaded successfully. Time: 35942.661 ms INFO: Load into table 'table_c' completed, 178 record(s) loaded successfully. Time: 47404.385 ms
サイズ
| table | ソートキー指定なしmb | ソートキー指定ありmb |
|---|---|---|
| table_a | 30 | 30 |
| table_b | 444 | 602 |
| table_c | 36 | 72 |
SQL
クエリの実行時間を比較するときは、最初にクエリを実行するときの結果を使用しないでください。その代わり、各クエリの 2 回目の実行時間を比較します。 １回目のクエリ実行時間は、破棄します。
# どちらも設定値を更新。セッション時にキャッシュを無効化 set enable_result_cache_for_session to off; # ソートキーなし select * from table_a limit 10000; Time: 316.842 ms select * from table_a, table_b where table_a.b_id = table_b.id AND table_a.c_id = table_c.id AND table_a.created_date > '2017/06/01'; Time: 10859.859 ms # ソートキーあり select * from table_b limit 10000; Time: 1245.379 ms select * from table_a, table_b, table_c where table_a.b_id = table_b.id AND table_a.c_id = table_c.id AND table_a.created_at > "2018/06/01"; Time: 217966.788 ms
課題
頻繁に結合する外部キーをソートキーとしましたが、COPYの実行時間、クエリ実行時間、サイズが増えています。 複合ソートキーを指定して、順番も合わせて条件式に加えましたがクエリの実行時間が20倍遅くなっています。前後の調査を含めて、エンコードは、ソートキーを除いてCOPYコマンドで自動設定し、ソートキーも結合キーではなく、条件で頻繁に使われる列に限定することにします。 分散キーについては、結合を頻繁に行われるテーブルでは、ソートキーと分散キー共に設定することが推奨されていますが、速度低下の可能性もありベンチマークを取り個別で設定を進めていきます。
参考
https://kikeda1104.hatenablog.com/entry/2018/06/29/210000
