レポートに関するベスト プラクティス

レポートを保存、再利用する

同じレポートを何度も挿入したり削除したりするとリソースが浪費されるため、定期的に実行するクエリに対して、レポートを作成して保存しておくことをおすすめします。日付の相対的な期間YESTERDAYLAST_7_DAYS など)を使用すると、レポートの再利用が容易になります。

レポートをスケジュールする

アドホック(1 回限りの)レポートの場合、レポートは個別に、不完全なデータセットに対して実行される可能性があるため、リソースの浪費が生じる恐れがあります。スケジュールに基づくレポートは一括で実行され、かつその日の前のデータ処理が完了するまでは実行されないことが保証されているため、レポート リソースが最大限に活用されます。詳細については、使用できるスケジュールのフィールドをご参照ください。

レポートのステータスをポーリングする際に指数バックオフを使用する

レポートの実行にかかる時間を予測することはできません。必要な時間は、期間や処理されるデータの量など多くの要因によって、数秒から数時間まで変動します。レポートの実行時間とレポートに含まれる行数との間にも相関関係はありません。したがって、レポートの実行がいつ完了したかを確認するには、実行中のレポートのステータスを定期的にチェックする必要があります。このプロセスを「ポーリング」と呼びます。

ポーリングが必要な状況で、長時間実行されるレポートが存在した場合、実装効率が悪いと割り当てられたリソースをすぐに使い切ってしまう可能性があります。そのような場合は、再試行回数を制限して割り当てリソースを節約するために、指数バックオフを使用することをおすすめします。

詳しくは指数バックオフをご参照ください。

マルチパート ダウンロードを実行する

レポート ファイルは最大で数ギガバイトになる場合があります。このようなレポートを 1 回のリクエストでダウンロードすると、接続性に関する問題が発生する可能性があります。また、1 回のリクエストによるダウンロードが中断された場合、リクエストを再開する方法はなく、失敗したダウンロードを途中から再開することもできません。そのため、マルチパート ダウンロードを使用して、大きなダウンロードを小さく分割することをおすすめします。分割された 1 回のダウンロードが失敗しても、その時点からダウンロードを再開することができます。

ダウンロードを分割することには多くのメリットがあります。分割されたダウンロードと同じ数のリクエストが個別に生成されるため、割り当てを無駄にしないように、最小サイズを 10 MB にすることをおすすめします。ただし、レポートサイズの平均が非常に大きい場合は、接続速度が許す限り、分割するサイズを大きくするようにしてください。

同時に実行するレポートの数を制限する

10 を超えるレポートを同時に実行すると、追加された実行リクエストの速度が制限されます。速度が制限されることでレポートの実行に時間がかかり、極端な場合はタイムアウトやエラーが発生する可能性があります。上限を超えるおそれがないようにするため、同時に実行するレポート数は 5 以下に制限することをおすすめします。