メニュー
Amazon Redshift
データベース開発者ガイド (API Version 2012年12月1日)

ステップ 8: 結果を評価する

テーブルのチューニング前と後にロード時間、ストレージ要件、クエリ実行時間をテストし、結果を記録しました。

以下のベンチマークの表に示しているのは、このチュートリアルで例として使用したクラスターの結果です。結果が異なっても、改善は同様のものになります。

ベンチマーク タグを 変更 %
ロード時間 (5 テーブル) 623 732 109 17.5%
ストレージ使用量
LINEORDER 51024 27152 -23872 -46.8%
PART 200 200 0 0%
CUSTOMER 384 604 220 57.3%
DWDATE 160 160 0 0%
SUPPLIER 152 236 84 55.3%
合計ストレージ 51920 28352 -23568 -45.4%
クエリ実行時間
Query 1 6.97 3.19 -3.78 -54.2%
Query 2 12.81 9.02 -3.79 -29.6%
Query 3 13.39 10.54 -2.85 -21.3%
合計実行時間 33.17 22.75 -10.42 -31.4%

ロード時間

ロード時間は 17.5% 長くなりました。

これはソート、圧縮、分散によるものです。特にこの例では、自動圧縮を使用したため、圧縮エンコードをまだ指定していない空のテーブルへのロード時間が長くなりました。同じテーブルへの以降のロードは速くなります。また、ALL 分散を使用することでロード時間が長くなりました。一部のテーブルに EVEN または DISTKEY 分散を使用することでロード時間を短縮できますが、使用するかどうかはクエリパフォーマンスを踏まえて決定する必要があります。

ストレージの要件

ストレージ要件は 45.4% 減りました。

列指向の圧縮の使用によりストレージがいく分か改善されましたが、一部のテーブルに ALL 分散を使用したことでこの改善は相殺されました。この場合も、一部のテーブルに EVEN または DISTKEY 分散を使用することでストレージ使用量を改善できますが、使用するかどうかはクエリパフォーマンスを踏まえて決定する必要があります。

配信

分散の選択の結果として不均等な分散がないことを確認しました。

EXPLAIN プランを確認することで、データの再分散がテストクエリに対して排除されたことがわかりました。

クエリ実行時間

合計クエリ実行時間は 31.4% 短くなりました。

クエリパフォーマンスの向上は最適なソートキー、分散スタイル、圧縮の組み合わせによるものでした。多く場合、クエリパフォーマンスの向上はクエリを書き直してワークロード管理 (WLM) を設定することで可能です。詳細については、「クエリパフォーマンスのチューニング」を参照してください。

次のステップ

ステップ 9: リソースをクリーンアップする

このページの内容: