スロット間の通信の最適化

通信スループットを評価するときは、クエリで必要となるシャッフルの量を考慮してください。ステージ間で何バイトが渡されますか?各スロットに何バイトが渡されますか?たとえば、GROUP BY 句は、処理のために同じスロットに同様の値を渡します。直接シャッフルされるデータの量は、通信スループットに影響を与え、結果としてクエリのパフォーマンスに影響します。

スロット間の通信を制御するための指針となるベスト プラクティスを次に示します。

JOIN を使用する前にデータを削減する

ベスト プラクティス: JOIN 句よりも前に処理されるデータの量を減らします。

クエリが JOIN を実行する前に、クエリの可能な限り早い段階でデータをカットします。処理サイクルの早い段階でデータを削減すると、シャッフルやその他の複雑なオペレーションが必要なデータに対してのみ実行されるようになります。

WITH 句を準備ステートメントとして扱わない

ベスト プラクティス: WITH 句は可読性を主な目的として使用するようにします。

WITH 句は実体化されないため、主に可読性のために使用するようにします。たとえば、WITH 句にすべてのクエリを含めて UNION ALL を実行するのは、WITH 句の正しい使い方ではありません。1 つのクエリが複数の WITH 句に含まれている場合、そのクエリは各句でそれぞれ実行されることになります。

テーブルを日付別に分割することを避ける

ベスト プラクティス: 時間分割テーブルの代わりに日付別に分割されたテーブル(日付別テーブルとも呼ばれる)を使用しないでください。

分割テーブルは、日付指定のテーブルより優れたパフォーマンスを発揮します。日付別に分割されたテーブルを作成する場合、BigQuery は各日付指定テーブルのスキーマとメタデータのコピーを保持する必要があります。また、日付指定のテーブルを使用する場合は、クエリされた各テーブルの権限を確認するために BigQuery が必要となることがあります。このプラクティスはさらに、クエリのオーバーヘッドを増やし、クエリのパフォーマンスを低下させます。

テーブルの過度な分割を回避する

ベスト プラクティス: テーブルを分割しすぎないでください。テーブルを日付別に分割している場合は、代わりに時間分割テーブルを使用してください。

テーブルの分割とは、大規模なデータセットを個別のテーブルに分割し、各テーブル名にサフィックスを追加することを指します。テーブルを日付別に分割している場合は、代わりに時間分割テーブルを使用してください。

BigQuery ストレージは低コストであるため、リレーショナル データベース システムのようにテーブルを最適化してコストを調整する必要はありません。テーブルを分割しすぎると、パフォーマンスへの悪影響が、コスト上のメリットを上回ります。

分割テーブルでは、BigQuery で各分割のスキーマ、メタデータ、および権限を保持する必要があります。テーブルを分割しすぎると、各分割の情報を保持する必要性からオーバーヘッドが増えるため、クエリのパフォーマンスが低下する可能性があります。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。