2.4基礎
イベント表をevent_timeの範囲で頻繁に検索する。
古いデータを除外するクエリのブロック読み取りを減らしたい。
最も適切な設計はどれか。
× 不正解
時間範囲の検索が中心ならevent_timeをSORTKEYにし、VACUUMや自動最適化の状態も確認する。
詳細解説
誤りevent_timeを常にDISTKEYにする
分散はノード配置を決めるため、範囲スキャンの並び順を保証しない。
誤りすべての行をS3 Glacierへ移す
分析対象をアーカイブへ移すだけで、Redshiftのスキャンは改善しない。
正しいevent_timeをSORTKEY候補にする
時系列順にブロックを並べ、範囲条件のブロックプルーニングを期待できる。
誤りCloudWatch Logsへクエリを移す
ログサービスへ移すことは表の物理設計の改善にならない。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
Amazon Redshift sort keys、zone maps、predicate filteringの公式説明を確認する。
確認できる内容
SORTKEYが範囲検索のブロックプルーニングに使われることを説明できる。
理解のポイント
- SORTKEY
- ゾーンマップ
- 範囲検索
- VACUUM
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 2・Task 2.4と各サービスの公式ドキュメントを確認する。
基礎のおさらい
論理と物理
列を選ぶだけでなく、クエリ条件とロード順を物理配置へ反映する。
VACUUM
更新や追加で並び順が崩れたとき、ソート領域を整えるRedshiftの保守処理。
問題IDAWS-DEA-163
確認環境AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告