DEAデータストアの管理
ある小売企業は Amazon Redshift でスタースキーマのデータウェアハウスを運用しています。売上ファクトテーブルは20億行（毎日数百万行追加）、商品ディメンションテーブルは5万行です。クエリの90%が「売上テーブルと商品テーブルを商品IDでJOINし、販売日でフィルタリングする」パターンですが、クエリ実行時に大量のデータ再分散（Redistribution）が発生しパフォーマンスが低下しています。この問題を解決する最適な設計はどれですか？
A売上テーブルに EVEN 分散、商品テーブルに ALL 分散、売上テーブルに販売日の SORTKEY を設定する
売上テーブルの EVEN 分散ではJOINキーがノード間でランダムに分散されるため、JOIN 時に再分散が依然として発生します。
B売上テーブルに KEY 分散（商品IDを DISTKEY に指定）、商品テーブルに ALL 分散、売上テーブルに販売日の SORTKEY を設定する
✓ 正解
Redshift では、JOIN に使うカラム（商品ID）をファクトテーブルの DISTKEY に指定すると、同じ商品ID のデータが同一ノードに配置され、JOIN 時のノード間データ再分散が不要になります。5万行程度の小規模ディメンションテーブルへの ALL 分散により全ノードに完全なコピーが保持されローカル JOIN が可能となります。
C売上テーブルに KEY 分散（販売日を DISTKEY に指定）、商品テーブルに ALL 分散、売上テーブルに商品IDの SORTKEY を設定する
DISTKEY に販売日を指定しているため、商品ID での JOIN 時にノード間再分散が発生し、根本的な問題が解決されません。
D売上テーブルと商品テーブルの両方に ALL 分散、売上テーブルに販売日の COMPOUND SORTKEY を設定する
20億行の売上テーブルに ALL 分散を適用すると全ノードにデータがレプリケートされ、ストレージを大量消費するため実用的ではありません。
解説
Redshift では、JOIN に使うカラム（商品ID）をファクトテーブルの DISTKEY に指定すると、同じ商品ID のデータが同一ノードに配置され、JOIN 時のノード間データ再分散が不要になります。5万行程度の小規模ディメンションテーブルへの ALL 分散により全ノードに完全なコピーが保持されローカル JOIN が可能となります。
選択肢Aの 売上テーブルの EVEN 分散ではJOINキーがノード間でランダムに分散されるため、JOIN 時に再分散が依然として発生します。
選択肢Cの DISTKEY に販売日を指定しているため、商品ID での JOIN 時にノード間再分散が発生し、根本的な問題が解決されません。
選択肢Dの 20億行の売上テーブルに ALL 分散を適用すると全ノードにデータがレプリケートされ、ストレージを大量消費するため実用的ではありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →