割り当てと制限

BigQuery では、受信するリクエストの最大レートが制限され、プロジェクト単位で適切な割り当てが適用されます。具体的なポリシーは、リソースの可用性、ユーザー プロフィール、サーバー使用量の履歴などの要因に応じて異なり、予告なく変更される場合があります。

システムの現在のレート制限と割り当て制限は以下のとおりです。

クエリ

jobs.query とクエリ型 jobs.insert 関数の呼び出しには、次の制限が適用されます。

  • オンデマンド料金でのインタラクティブ クエリの同時実行レートの制限: 同時実行クエリ 50 個。キャッシュされた結果を返すクエリや dryRun プロパティを使用して設定されたクエリは、この制限に対してカウントされません
  • ユーザー定義関数(UDF)を含むクエリの同時実行レートの制限: インタラクティブ クエリと一括クエリの両方を含め、同時実行クエリ 6 個。UDF を含むインタラクティブ クエリは、インタラクティブ クエリの同時実行レートの制限に対してカウントされます。
  • 1 日あたりのクエリサイズの制限: デフォルトでは無制限ですが、カスタム割り当てを使用して制限を指定することもできます。
  • 1 日あたりの更新の制限: 1 日あたり 1 テーブル 1,000 回の更新。クエリ内の更新先テーブルにのみ適用されます。
  • クエリ実行時間の制限: 6 時間
  • オンデマンド料金での BigQuery プロジェクトごとの最大同時実行スロット数: 2,000
  • クエリごとに参照されるテーブルの最大数: 1,000
  • データセットあたりの承認済みビューの最大数: 1,000
  • 未解決クエリの最大長: 256 KB
  • 解決クエリの最大長: 参照されるすべてのビューとワイルドカード テーブルを含め、12 MB
  • 最大レスポンス サイズ: 圧縮された 128 MB1大きいサイズのクエリ結果を宛先テーブルに書き込む場合は無制限)
    1 サイズはデータの圧縮率によって異なります。実際のレスポンス サイズは 128 MB よりも大幅に大きくなる場合があります。

オンデマンド クエリのデフォルトのスロット数は、同じプロジェクト内のすべてのクエリで共有されます。目安としては、1 回に処理するクエリが 100 GB 以下であれば、2,000 スロットすべてを使用することはほぼありません。アカウントで使用しているスロットの数を確認するには、Stackdriver を使用した BigQuery のモニタリングをご覧ください。2,000 個より多いスロットが必要な場合は、営業担当者にお問い合わせになり、定額料金が適切かご相談ください。

データセットとテーブルの更新オペレーション

データセットとテーブルの更新オペレーションには、次の制限が適用されます。

  • データセットのメタデータに対する更新オペレーションの最大レート: 2 秒ごとに 1 オペレーション(insertpatchupdate
  • テーブルに対する更新オペレーションの最大レート: 2 秒ごとに 1 オペレーション(insertpatchupdatejobs 出力)

データ操作言語のステートメント

データ操作言語(DML)には、次の制限が適用されます。

  • テーブルごとの 1 日あたりの最大 UPDATE/DELETE ステートメント数: 96
  • プロジェクトごとの 1 日あたりの最大 UPDATE/DELETE ステートメント数: 1,000
  • テーブルごとの 1 日あたりの最大 INSERT ステートメント数: 1,000
  • プロジェクトごとの 1 日あたりの最大 INSERT ステートメント数: 1,000

DML ステートメントは、SELECT ステートメントよりも処理コストがかなり高くなります。

読み込みジョブ

BigQuery へのデータの読み込みには、次の制限が適用されます。

  • 1 日あたりの制限: 1 日あたりテーブルごとに 1,000 個の読み込みジョブ(失敗を含む)、1 日あたりプロジェクトごとに 50,000 個の読み込みジョブ(失敗を含む)
  • 1 日にテーブルごとに許可される読み込みジョブ数の上限(1,000 個)を引き上げることはできません。
  • 行、セルサイズ制限:
    データ形式 最大値
    CSV 10 MB(行およびセルサイズ)
    JSON 10 MB(行サイズ)
    Avro 16 MB(ブロックサイズ)
  • テーブルごとの最大列数: 10,000
  • 最大ファイルサイズ:
    ファイル形式 圧縮 非圧縮
    CSV 4 GB
    • 値に引用符付きの改行がある場合: 4 GB
    • 値に改行がない場合: 5 TB
    JSON 4 GB 5 TB
    Avro 圧縮 Avro ファイルはサポート対象外ですが、圧縮データブロックはサポート対象です。BigQuery は DEFLATE および Snappy コーデックをサポートします。 5 TB(ファイル ヘッダー用に 1 MB)
  • 1 件の読み込みジョブあたりの最大サイズ: CSV、JSON、Avro のすべての入力ファイル全体で 15 TB
  • ジョブ設定でのソース URI の最大数: 10,000 個の URI
  • 読み込みジョブごとの最大ファイル数: すべてのワイルドカードに一致する合計 10,000,000 件のファイル
  • 読み込みジョブ実行時間の制限: 6 時間

BigQuery がサポートするデータ形式について詳しくは、BigQuery 用データの準備をご覧ください。

コピージョブ

BigQuery でのテーブルのコピーには、次の制限が適用されます。

  • 1 日あたりの制限: 1 日あたりテーブルごとに 1,000 個のコピージョブ(失敗を含む)、1 日あたりプロジェクト(コピージョブを実行中のプロジェクト)ごとに 10,000 個のコピージョブ(失敗を含む)

エクスポート リクエスト

BigQuery からのデータのエクスポートには、次の制限が適用されます。

  • 1 日あたりの制限: 1 日あたり 1,000 回のエクスポート、1 日あたり 10 TB の累積制限付き
  • 複数ワイルドカード URI の制限: 1 回のエクスポートで 500 URI

分割テーブルに対する更新

分割テーブルには次の制限が適用されます。

  • 1 日あたりの制限: 1 日あたり 1 テーブル 2,000 回のパーティション更新
  • レート制限: 10 秒ごとに 50 パーティションの更新

クエリジョブ(DML を含む)、読み込みジョブ、コピージョブからのテーブル パーティションへの書き込みも更新制限の対象となります。

ストリーミング インサート

BigQuery へのデータのストリーミングには、次の制限が適用されます。

  • 行の最大サイズ: 1 MB。この値を超えると invalid エラーが発生します。
  • HTTP リクエストのサイズの制限: 10 MB。この値を超えると invalid エラーが発生します。
  • 1 秒あたりの最大行数: プロジェクトごとに 1 秒あたり 100,000 行。この制限を超えると quotaExceeded エラーが発生します。テーブルごとの 1 秒あたりの制限も 100,000 行になります。この割り当てを 1 つのテーブルで使用することも、プロジェクト内の複数のテーブルに分割することもできます。
  • リクエストあたりの最大行数: リクエストごとに 10,000 行。最大 500 行をおすすめします。一括処理することでパフォーマンスとスループットをある程度向上させることはできますが、リクエストごとのレイテンシは高くなります。リクエストごとの行数が少なく、各リクエストにオーバーヘッドがあると取り込みの効率が下がります。また、リクエストごとの行数が多すぎるとスループットが下がります。推奨される行数はリクエストごとに 500 行程度ですが、代表データ(スキーマとデータサイズ)を使用したテストを実施して適切なバッチサイズを判断することをおすすめします。
  • 1 秒あたりの最大バイト数: テーブルごとに 1 秒あたり 100 MB。この制限を超えると quotaExceeded エラーが発生します。

ストリーミング データの上限を増やす場合には、カスタム割り当てリクエスト フォームを利用してください。通常 2~3 営業日以内に返答があります。

API リクエスト

  • ユーザーごとの 1 秒あたりの API リクエスト数: 1 秒あたり 100 個以上のリクエストを実行すると、制限の調整が行われることがあります。この制限はストリーミング インサートには適用されません。

割り当てが補充される時期は?

毎日の割り当ては、レート制限動作をガイドするという意図を反映して、一日中一定の間隔で補充されます。割り当てが使い尽くされた場合の長時間の混乱を避けるためにも、断続的な更新がなされます。通常、割り当ては 1 日に 1 回グローバルに補充されるのではなく、数分でさらに多くの割り当てが利用可能になります。

エラーコード

割り当てまたは制限のエラーには、403 または 400 の HTTP レスポンス コードが返されます。エラーコードとそれに対応するトラブルシューティング手順の全一覧については、エラーのトラブルシューティングについての記事をご覧ください。

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