ayumu_aoの日記

SIerから事業会社に転職したエンジニアがなにかを垂れ流してます

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分散に向くか検討する

※分散スタイルは結合に注目

ソートキーの決定方法 * なんのためのソートをおこなうのか