AWS Summitに行ってきた!レポート※セッションメモ (2017/06/01)Amazon Redshift テーブル設計詳細ガイド −分散スタイルとソートキーの決定方法−
AWS Summitに行ってきた!レポート※セッションメモ (2017/06/01)Amazon Redshift テーブル設計詳細ガイド −分散スタイルとソートキーの決定方法−
AWS Summit 2017/06/01 Amazon Redshift テーブル設計詳細ガイド −分散スタイルとソートキーの決定方法−
※あとで資料が共有されるのでそれを見るのでメモ書きレベル
自己紹介
- 柴田竜典
REdShiftを利用時のなやみ
- クエリ性能をさらに向上させたい
- 同時実行を上手にさばきたい
- 料金を抑えたい などなど
クエリ性能向上に大切なことはなにか
- 最良のソートキーの選択
- 最適な分散スタイルの選択
なやみ
- それぞれの方式のメリット、デメリットが正確に理解できていない
- 統一感がない
アジェンダ
分散スタイル
- なぜ重要なのか
- キーの候補となる列の抽出
- スタイルの決定
- 最適なキーの決定
ソートキー * ソートキーについて * ソートキーの決定
■なぜ重要なのか
分散スタイルを考える観点
- 結合の観点から考える
最適なEX)EVEN分散された注文書とALL分散された名簿
最適ではないEX)KEY分散荒れた注文書とALL分散された名簿
分散時に偏りや重複が発生しないように分散することが大切
最適ではないEX)EVEN分散された注文書とEVEN分散された名簿
結合できない可能性があり再分散の必要性が出てくる
現実問題
- 様々なクエリに対応する必要がある
- 分散キーは1テーブルに1個しか選べない
■分散キーの候補となる列の抽出
観点
- その列のデータは均一になっているか
- NULLの割合が大きくないか
- その列のカーディナリティは高いか(スライスの数に対してカーディナリティが高いか※スライス数の4から5倍以上が目安)
- その列でフィルタされているか(Noであるほうが好ましい)
- その列が第1ソートキーであるか(Yesであることを確認)
- その列でMerge Joinをしているか※詳細はスライド参照
■分散スタイルの決定
観点
- 結合にしようされているか
- すくなくても1つの分散キー候補があるか
- 追加ストレージを許容できるか
- 並列性能を犠牲にすることが許容できるか
- 少なくとも1つの分散キー候補があるか
- 結合条件で分散キー候補を使用するか
ALL分散が不向きな一般的なガイドライン
- 読み取り操作
- 大きなファクトテーブルに対するスキャン
- 結合しない単一テーブルスキャン
あとはスライド見る!
■最適な分散キーの決定
- クエリごとで結合する列が異なる場合、度のクエリを優先すべきかから分散キーを選ぶ
- トレードオフがそれぞれあるがそれは個々の選択になりおすすめはない
ソートキーについて
- ゾーンマップのディスクIOを削減する
- クエリ実行時のソート処理をなくす
- Merge Joinのクエリ効率を上げる
ソート形式の種類
- Compound ※第1ソートキーが使用されない場合は第2ソートキー以降も利用されない
- Interleaved ※メンテコストが非常に高い 90%の場合はCompoundでよい
キーワード:
分散キーは1テーブルに1個しか選べない
各テーブルにはソートキーは一つしか指定できない
Merge joinのソートキー → DistKeyと同じ列
ソート処理を削減するためのソートキー → Orderby で利用する列
まとめ
分散スタイルの決定方法 * Key分散の無垢列が存在するか検討する * ALL分散に向くか検討する
※分散スタイルは結合に注目
ソートキーの決定方法 * なんのためのソートをおこなうのか