Redshiftの分散スタイルとソートキーの決定方法を聞いてきた

6月１日　AWS　Summit Tokyo 2017に行ってきた！

次は
Amazon Redshift テーブル設計詳細ガイド –分散スタイルとソートキーの決定方法–

をメモメモ



・クエリ性能をさらに向上させたい

・大切なことは何か→書いてある
　最良のソートキー
　最適な分散スタイル

・分散スタイルとソートキーに関する悩み
　そもそも、メリット・デメリットが・・・
　統一感ない

・分散スタイル
・分散スタイルとは何か
　１万枚の注文書　５人の名前が書かれたお客様
　１０人で抽出

・３つの分散スタイル
　ＥＶＥＮ
　　１万枚を、１０００枚ずつ１０人
　ＫＥＹ
　　注文者名が　あではじまるひと、　かで始まる人
　ＡＬＬ
　　１０部コピーする

・最適な分散スタイルの例
　ＥＶＥＮ分散された注文書とＡＬＬ分散された名簿
　　１０人ほぼ等しく終える
・最適じゃない
　ＫＥＹ分散された注文書とＡＬＬ分散された名簿
　　あ行にくらべ、ワ行の人が早く終わる
　ＡＬＬ分散注文書、ＡＬＬ分散名簿

・ＥＶＥＮ分散とＥＶＥＮ分散
　　→再分散が起きる
　ＫＥＹ分散された名簿

・現実はさらに難しい
　さまざまなクエリに対応する必要がある
　分散キーは１テーブルに１個しか選べない
　フローチャートで機械的に判断

・分散キーの候補となる列の抽出
　公開された資料を印刷して貼っておいてね！

　均一に分散している
　　あ行　ＶＳ　わ行
　　ＮＵＬＬの割合が大きい列
　　調べ方　countで

　　その列のカーでぃなりてぃは高い？
　　スライスの数に対して相対的に高いか？
　　→４～５倍以上
　　調べ方　approximate count distinct 誤差２％だけど、高速

　その列でフィルターされているか　Ｎｏなら向いている　ＹＥＳなら保留
　ＳＱＬは資料を見てね！

　その列は第一ソートキー
　　→　ゾーンマップが聞く可能性
　　１Ｍごとのデータブロックの最大値と最小値

　その列でマージジョインしている？
　　一番高速なジョイン

・分散スタイルの決定

　結合に使用されているか
　　　→ＡＬＬ分散の結合子からなくなる

　分散キー候補があるか

　追加ストレージを許容できるか
　　→コピーされる：容量

　並列性能を犠牲にできるか

　ＡＬＬ分散が不向き
　　大きなファクトテーブル
　　結合しない単一テーブル
　　複雑な集計
　　頻繁に書き換えられる

　分散キー候補があるか
　結合条件で分散キー候補を使用するか？

・どのクエリを優先すべきか
　　いろいろ

・ソートキー
　ソートするメリット
　　ディスクＩＯ削減
　　クエリー実行時のソート処理
　　まーじＪＯＩＮ

・種類
　　ＣＯＭＰＯＵＮＤ（順番重要）
　　ＩＮＴＥＲＬＥＡＶＥＤ：メンテナンスコストが高い
　→一般的にはＣＯＭＰＯＵＮＤで十分


・ソート形式の決定
　ソートはＭＥＲＧＥ　ＪＯＩＮを有効にしますか
　実行時のＳＯＲＴ処理を削減しますか
　ソートはゾーンマップで改善するか
　さまざまな列でフィルターしますか？
　必要に応じてＶＡＣＵＵＭ　ＲＥＩＮＤＥＸできますか？
　データに８バイト以上のプリフィックスがありますか？
　　http://www→全部同じ：事実上ソートされない

・最良のソートキー列の決定
　　マージジョイン：ＤＩＳＴＫＥＹとおなじ
　　ＯＲＤＥＲ　ＢＹ
　　フィルタ

・まとめ
　分散スタイル
　　１．ＫＥＹ分散
　　２．ＡＬＬ分散
　　・結合に注目
　　ソートキー
　　interleave使えるか