クエリパフォーマンスに影響を与える要因 - Amazon Redshift

クエリパフォーマンスに影響を与える要因

いくつかの要因がクエリパフォーマンスに影響を与える可能性があります。データ、クラスター、データベース操作の次の側面はすべて、クエリ処理の速度に影響を与えます。

  • ノード、プロセッサ、スライスの数 – コンピューティングノードはスライスに分割されています。ノードが多いということは、プロセッサとスライスが多いことを意味するため、クエリの各部分をスライス間で同時実行することによりプロエスをすばやく処理することが可能になります。ただし、ノードが多いとコストも上昇するため、システムに適したコストとパフォーマンスのバランスを見つける必要があります。Amazon Redshift クラスターアーキテクチャの詳細については、「データウェアハウスシステムのアーキテクチャ」を参照してください。

  • ノードタイプ – Amazon Redshift クラスターは、高密度ストレージまたは高密度コンピューティングノードを使用できます。高密度ストレージノードタイプは、かなりの量のデータストレージが必要な場合にお勧めで、高密度コンピューティングノードタイプは、パフォーマンス重視の作業負荷用に最適化されています。各ノードタイプは様々なサイズを提供し、クラスターを適切に拡張することができるように制限します。ノードサイズによって、クラスター内の各ノードのストレージ容量、メモリ、CPU、および料金が決まります。ノードタイプの詳細については、「Amazon Redshift の料金表」を参照してください。

  • データ分散 – Amazon Redshift は、テーブルの分散スタイルに応じて、テーブルデータをコンピューティングノードに保存します。クエリを実行すると、必要に応じて結合と集計を実行するために、クエリオプティマイザによってデータがコンピューティングノードに再分散されます。テーブルに適した分散スタイルを選択すると、結合を実行する前にデータを必要な場所に配置しておくことによって、再分散ステップの影響を最小限に抑えることができます。詳細については、「データ分散スタイルの選択」を参照してください。

  • データのソート順 – Amazon Redshift は、テーブルのソートキーに応じたソート順で、テーブルデータをディスクに保存します。クエリオプティマイザとクエリプロセッサは、データの保存場所に関する情報を使用して、スキャンする必要があるブロックの数を減らすため、クエリの速度が向上します。詳細については、「ソートキーの選択」を参照してください。

  • データセットサイズ – クラスター内のデータのボリュームが大きくなると、スキャンおよび再分散する必要がある行が増えるため、クエリのパフォーマンスが低下する可能性があります。データのバキューム処理とアーカイブを定期的に実行し、クエリデータセットを制限する述語を使用することによって、この影響を緩和できます。

  • 同時操作 – 複数の操作を一度に実行すると、クエリパフォーマンスに影響が及ぶ可能性があります。操作が実行されるたびに使用可能なクエリーキューの 1 つ以上のスロットが取得され、それらのスロットに関連付けられたメモリが使用されます。他の操作が実行されている場合、十分なクエリキュースロットを使用できない可能性があります。この場合、クエリは処理を開始する前にスロットが空くのを待つ必要があります。クエリキューの作成と設定の詳細については、「ワークロード管理の実装」を参照してください。

  • クエリ構造 – クエリの書き込み方法は、そのパフォーマンスに影響を与えます。できる限り少ないデータを処理して返すクエリを記述すると、ニーズを満たすことができます。詳細については、「Amazon Redshift クエリの設計のベストプラクティス」を参照してください。

  • コードコンパイル – Amazon Redshift は、各クエリ実行プランのコードを生成してコンパイルします。

    コンパイル済みコードは、インタプリタを使用してオーバーヘッドを排除するため、高速で実行されます。通常、コードが初めて生成およびコンパイルされるときは、ある程度のオーバーヘッドコストが生じます。その結果、最初に実行したときのクエリのパフォーマンスは、誤解を招く場合があります。1 回限りのクエリを実行するときは、オーバーヘッドコストは特に顕著になります。クエリのパフォーマンスを判断するには、必ず 2 回目にクエリを実行します。

    同様に、異なるクライアントから送られた同じクエリのパフォーマンスの比較にも注意が必要です。実行エンジンは JDBC 接続プロトコルおよび ODBC と psql (libpq) 接続プロトコルに対して異なるコードを生成します。2 つのクライアントが別のプロトコルを使用する場合、各クライアントは、対象が同じクエリであっても、コンパイル済みを生成する最初のコストを発生させます。ただし、同じプロトコルを使用する他のクライアントには、キャッシュされたコードの共有によるメリットがあります。ODBC を使用するクライアントと、libpq とともに psql を実行するクライアントは、コンパイル済みの同じコードを共有できます。

    コンパイル済みコードセグメントはクラスターでローカルに保存されるとともに、AWS アカウントレベルのキャッシュにリモートに保存されます。同じクエリをそれ以降に実行すると、コンパイルフェーズをスキップできるため、高速になります。キャッシュはクラスターが再起動されても保持されるものの、メンテナンスアップグレードによって消去されます。

    ローカルキャッシュミスがある場合は、リモート共有キャッシュが使用されます。リモートキャッシュヒットがある場合は、キャッシュされた項目がローカルキャッシュに取得されます。リモートキャッシュは、同じ AWS アカウント内のクラスター間で共有されます。したがって、以下の場合にクエリの実行が高速になります。

    • クエリが同じアカウントの異なるクラスターで実行される場合。

    • クエリがクラスター間の異なるセッションで実行される場合。

    • 通常、クエリに別のクエリパラメータが含まれているが、実行プランが同じである場合。