分散キーとソートキー

#投稿のきっかけ
仕事でRedshiftを用いてデータベースを構築する必要があり、分散キーとソートキーという単語に引っかかった。
この記事は、自習用の備忘録として、そしてQiitaへの初投稿としてお試しで投稿してみる。

#参考サイト
Redshiftの設計前に知っておくべき分散キーとソートキーの役割
AWSデータベース開発者ガイド

#ノードスライス
本題の分散キー・ソートキーに入る前に、まずこの「ノードスライス」という単語は避けて通れないらしい。
###ノードスライスとはなんぞや
定義は「ノード数×CPU数」らしい。
つまりは１つのノード内に多量のデータを詰め込んで、それを並列CPUで処理する。。。その各計算単位？？？
→多分あってる。

AWSのガイドの言葉を借りると、
**「テーブルにデータをロードすると、そのテーブルの分散スタイルに従って、Amazon Redshift がテーブルの行を各ノードスライスに分散」**するらしい。
分散させた各ノードスライス１つ１つにCPUが割り当てられるイメージ？

この仕組みによって、Amazon Redshiftでは大量のデータを高速に扱うことができるらしい。

#本題
###分散キーとはなんぞや

• ノードスライスにデータを振り分ける時の基準となるカラム
• 分散キーは１テーブルに対して１つしか設定できない
• 分散キーに指定されたカラムの各レコードのハッシュ値ごとにデータを分散させている
  • ここでいうハッシュ値が何を指しているのかが今の自分にはわからない
• 分散の仕組みは「EVEN」「KEY」「ALL」の３つ

###ソートキーとはなんぞや

• データの並び順を決める時に基準となるカラム
• 最大４００個まで指定できる

#テーブル設計時に気を付けること
###分散キー選定

• 分散キーに設定するカラムの値は均一に分散しているか
  • 各値のレコードごとにグルーピングされて、そのグループ（ノードスライス）ごとに処理が行われるため、ノードスライスごとに処理時間の差が生じ、結果無駄が生じてしまう。
• ノードスライス数よりも値の種類が多いか
  • ノードスライス数の方が多い場合、データが割り当てられないノードスライスが生じ、分散機能を十分に発揮できない。
• WHERE句の最初で指定されるカラムでないか
  • WHERE句でフィルタリングされると、ノードスライスに割り当てられるデータの種類が限定されることになり、結果、分散機能を十分に発揮できなくなる。

###ソートキー選定

• ORDER BY,GROUP BYなどで指定されるカラムか
  • ソートキーに指定したカラムに対してORDER BY, GROUP BYをかけると、クエリ実行時のソート処理時間を短縮できる
    • （なぜ短縮できるかの仕組みは別途調べたい）
• WHERE句に指定して、ゾーンマップを有効活用できるか（なんのこっちゃ）
  • ソートキーに指定したカラムの最小値と最大値をメタデータとして持つ　←　これがゾーンマップ
  • ゾーンマップの仕組みがあるので、ソートキーに指定したカラムをWHERE句の最初に指定すると、検索処理を短縮することができる。
  • ソートキーには「COMPOUND SORTKEY」「INTERLEAVED SORTKEY」の２種類があり、これらの特徴も理解しながら設定順などを考慮する必要がある。

#まとめ
分散キーは、Redshift特有の（特有なのか？）ノードスライスという仕組みを有効活用するための決め事
ソートキーは、ソート及び検索処理を効率的に行うための決め事

という理解。

間違ってたら詳しい人に教えを請いたい。