割り当てと上限

このドキュメントでは、BigQuery に適用される割り当てとシステム上限について説明します。割り当ては、使用できるカウント可能な共有リソースの量を指定します。割り当ては、BigQuery などの Google Cloud サービスによって定義されます。システム上限は、変更できない固定値です。

Google Cloud は、割り当てを使用して公平性を確保し、リソースの使用量と可用性の急増を抑えます。割り当ては、Google Cloud プロジェクトで使用できる Google Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワーク コンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、自組織で使用している Google Cloud リソースの管理にも役立ちます。

Cloud Quotas システムは次のことを行います。

  • Google Cloud のプロダクトとサービスの消費量をモニタリングする
  • これらのリソースの消費量を制限する
  • 割り当て値の変更をリクエストする手段を提供する

ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。

割り当ては通常、Google Cloud プロジェクト レベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。

BigQuery リソースにはシステム上限もあります。システム上限は変更できません。

デフォルトでは、BigQuery の割り当てと上限はプロジェクト単位で適用されます。異なる上限に適用される割り当てと上限は、テーブルごとの最大列数やユーザーごとの同時 API リクエストの最大数などで示されます。具体的なポリシーは、リソースの可用性、ユーザー プロファイル、Service Usage の履歴などの要因に応じて異なり、予告なく変更される場合があります。

割り当ての補充

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

割り当ての増加をリクエストする

通常、割り当てを調整するには、Google Cloud コンソールを使用します。詳細については、割り当ての調整をリクエストするをご覧ください。

Google Cloud コンソールで割り当ての増加をリクエストするプロセスの詳細なガイドについては、[ガイドを表示] をクリックしてください。

ガイドを表示

割り当て使用量の上限

割り当てのオーバーライドを作成して特定のリソースの使用量を制限する方法については、割り当てのオーバーライドを作成するをご覧ください。

必要な権限

Google Cloud コンソールで BigQuery の割り当てを表示および更新するには、Google Cloud の割り当てと同じ権限が必要です。詳細については、Google Cloud の割り当て権限をご覧ください。

トラブルシューティング

割り当てと上限に関連するエラーのトラブルシューティングについては、BigQuery の割り当てエラーのトラブルシューティングをご覧ください。

ジョブ

割り当てと上限は、Google Cloud コンソール、bq コマンドライン ツール、REST API またはクライアント ライブラリを使用するプログラムのいずれかで BigQuery によって実行されるジョブに適用されます。

クエリジョブ

インタラクティブ クエリ、スケジュールされたクエリ、jobs.query とクエリタイプ jobs.insert API メソッドで送信されたジョブによって自動的に作成されるクエリジョブには、次の割り当てが適用されます。

割り当て デフォルト 注
1 日あたりのクエリ使用量 無制限 プロジェクト内のクエリで処理できるバイト数に上限はありません。
Google Cloud コンソールで割り当てを表示する
ユーザーごとの 1 日あたりのクエリ使用量 無制限 ユーザーのクエリで 1 日に処理できるバイト数に上限はありません。
Google Cloud コンソールで割り当てを表示する
クロスリージョンの Cloud SQL 連携クエリの 1 日あたりのバイト数 1 TB BigQuery のクエリ処理のロケーションと Cloud SQL インスタンスのロケーションが異なる場合、クエリはクロスリージョン クエリになります。1 つのプロジェクトで 1 日に実行できるクロスリージョン クエリは 1 TB までです。詳しくは、Cloud SQL 連携クエリをご覧ください。
Google Cloud コンソールで割り当てを表示する
1 日あたりのクロスクラウド転送バイト数 1 TB Amazon S3 バケットまたは Azure Blob Storage から 1 日あたり最大 1 TB のデータを転送できます。詳細については、Amazon S3 からのクラウド間転送および Azure からのクラウド間転送をご覧ください。
Google Cloud コンソールで割り当てを表示する

インタラクティブ クエリ、スケジュールされたクエリ、jobs.query とクエリタイプ jobs.insert API メソッドで送信されたジョブによって自動的に作成されるクエリジョブには、次の上限が適用されます。

上限 デフォルト 注
キューに追加できるインタラクティブ クエリの最大数 クエリ 1,000 件 プロジェクトでは、最大 1,000 件のインタラクティブ クエリをキューに入れることができます。 この上限を超えるインタラクティブ クエリを追加しようとすると、割り当てエラーが返されます。
キューに追加できるバッチクエリの最大数 20,000 件のクエリ プロジェクトで最大 20,000 件のバッチクエリをキューに入れることができます。この上限を超えるバッチクエリを追加しようとすると、割り当てエラーが返されます。
Bigtable 外部データソースに対する同時実行インタラクティブ クエリの最大数 16 件のクエリ プロジェクトで、Bigtable 外部データソースに対して最大 16 件のクエリを同時に実行できます。
リモート関数を含む同時実行クエリの最大数 10 件のクエリ プロジェクトごとにリモート関数を使用して最大 10 件のクエリを同時に実行できます。
同時実行の複数ステートメント クエリの最大数 1,000 件の複数ステートメント クエリ 1 つのプロジェクトで、最大 1,000 件のマルチステートメント クエリを同時に実行できます。 複数ステートメント クエリに関連するその他の割り当てと上限については、 複数ステートメント クエリをご覧ください。
UDF を含むレガシー SQL 同時クエリの最大数 6 個のクエリ プロジェクトで、ユーザー定義関数（UDF）を使用して最大 6 個のレガシー SQL クエリを同時に実行できます。この上限には、インタラクティブ クエリとバッチクエリの両方が含まれます。UDF を含むインタラクティブ クエリは、インタラクティブ クエリの同時実行の上限に対してもカウントされます。この上限は GoogleSQL クエリには適用されません。
1 日のクエリサイズの上限 無制限 デフォルトでは、1 日あたりのクエリサイズに上限はありません。1 日あたりのクエリ使用量、またはユーザーごとの 1 日あたりのクエリ使用量を指定するカスタム割り当てを作成することで、ユーザーがクエリできるデータ量に上限を設定できます。
1 日の宛先テーブルの更新回数の上限 1 日あたりのテーブル オペレーションの最大数をご覧ください。 クエリジョブでの宛先テーブルの更新は、宛先テーブルごとの 1 日あたりのテーブル オペレーション数の上限にカウントされます。宛先テーブルの更新としてカウントされる対象としては、Google Cloud コンソール、bq コマンドライン ツールを使用したクエリ、または API の jobs.query メソッドや query-type jobs.insert メソッドの呼び出しによって実行される追加オペレーションや上書きオペレーションなどがあります。
クエリ / 複数ステートメント クエリの実行時間の上限 6 時間

クエリまたは複数ステートメントのクエリは、最大 6 時間実行できますが、その後失敗します。ただし、クエリが再試行されることがあります。クエリは 3 回まで試行でき、各試行は最大 6 時間実行できます。そのため、クエリの合計実行時間が 6 時間以上になることがあります。

CREATE MODEL ジョブのタイムアウトはデフォルトで 24 時間に設定されていますが、時系列、AutoML、ハイパーパラメータ チューニング ジョブは 72 時間でタイムアウトします。
1 つのクエリで参照可能なリソースの最大数 1,000 個のリソース 1 つのクエリで、一意のテーブル、一意のビュー、一意のユーザー定義関数（UDF）、完全展開後の一意のテーブル関数を合計 1,000 個まで参照できます。この上限には次のものが含まれます。
  • クエリで直接参照されるテーブル、ビュー、UDF、テーブル関数。
  • クエリで参照される他のビュー、UDF、テーブル関数によって参照されるテーブル、ビュー、UDF、テーブル関数。
SQL クエリの最大文字数 1,024,000 文字 SQL クエリの長さは最大 1,024,000 文字です。この上限には、コメントと空白文字も含まれます。クエリが長い場合、「The query is too large.」というエラーが表示されます。この上限内に収めるには、サイズの大きい配列またはリストをクエリ パラメータに置き換え、長いクエリをセッション内の複数のクエリに分割することを検討してください。
未解決レガシー SQL クエリの最大長 256 KB 未解決レガシー SQL クエリは最大 256 KB までです。クエリが長い場合、「The query is too large.」というエラーが表示されます。この上限内に収めるには、サイズの大きい配列またはリストをクエリ パラメータに置き換えることを検討してください。
未解決の GoogleSQL クエリの最大長 1 MB 未解決の GoogleSQL クエリの長さは最大 1 MB です。クエリが長い場合、「The query is too large.」というエラーが表示されます。この上限内に収めるには、サイズの大きい配列またはリストをクエリ パラメータに置き換えることを検討してください。
解決済みレガシークエリおよび GoogleSQL クエリの最大長 12 MB 解決済みクエリの長さに対する上限では、クエリで参照しているすべてのビューとワイルドカード テーブルの長さも対象になります。
GoogleSQL クエリ パラメータの最大数 10,000 個のパラメータ GoogleSQL クエリには、最大 10,000 個のパラメータを指定できます。
リクエストの最大サイズ 10 MB リクエスト サイズは最大 10 MB です。これには、クエリ パラメータなどの追加のプロパティも含まれます。
最大レスポンス サイズ 10 GB 圧縮 このサイズは、データの圧縮率によって異なります。レスポンスの実際のサイズは、10 GB よりも大幅に大きくなることがあります。大規模なクエリ結果を宛先テーブルに書き込む場合、最大レスポンス サイズに上限はありません。
最大行数 100 MB 行のサイズは行データの内部表現に基づくため、その最大サイズは概算値になります。行の最大サイズに対する上限は、クエリジョブ実行の特定の段階で適用されます。
テーブル、クエリ結果、ビュー定義での最大列数 10,000 列 テーブル、クエリ結果、ビュー定義には最大 10,000 列を含めることができます。
オンデマンド料金の同時実行スロットの最大数 プロジェクトあたり 2,000 スロット

組織あたり 20,000 スロット 		オンデマンド料金では、プロジェクトで最大 2,000 個の同時実行スロットを設定できます。また、組織レベルでの同時実行スロット数の上限 20,000 も適用されます。組織全体での需要が 20,000 スロットを超える場合、BigQuery は組織内のプロジェクトの間で均等にスロットを割り振ろうと試みます。BigQuery スロットは、単一のプロジェクト内のすべてのクエリで共有されます。BigQuery が、クエリを高速化するためにこの上限を超えてバーストする場合があります。現在使用しているスロットの個数を確認するには、Cloud Monitoring を使用した BigQuery のモニタリングをご覧ください。
オンデマンド料金のスキャンデータあたりの最大 CPU 使用率 スキャンされる MiB あたり 256 CPU 秒 オンデマンド料金では、クエリで MiB あたり最大で約 256 CPU 秒までスキャンデータを使用できます。処理されるデータ量に対してクエリの CPU 使用率が高くなりすぎると、クエリは billingTierLimitExceeded エラーで失敗します。詳しくは、billingTierLimitExceeded をご覧ください。
マルチステートメント トランザクション テーブルのミューテーション 100 個のテーブル トランザクションでは、最大 100 個のテーブル内のデータを変更できます。
マルチステートメント トランザクション パーティションの変更 100,000 件のパーティション変更 トランザクションでは、最大 100,000 件のパーティション変更を実行できます。
BigQuery Omni のクエリ結果の最大サイズ 非圧縮で 20 GiB Azure データまたは AWS データをクエリする場合、結果の最大論理バイト数は 20 GiB です。クエリ結果が 20 GiB より大きい場合は、結果を Amazon S3 または Blob Storage にエクスポートすることを検討してください。詳しくは、BigQuery Omni の制限事項をご覧ください。
1 日あたりの BigQuery Omni クエリ結果の合計サイズ 1 TB プロジェクトの合計クエリ結果サイズは 1 日あたり 1 TB です。 詳しくは、BigQuery Omni の制限事項をご覧ください。
BigQuery Omni の行の最大サイズ 10 MiB Azure または AWS のデータをクエリする場合、行の最大サイズは 10 MiB です。詳しくは、BigQuery Omni の制限事項をご覧ください。

スケジュールされたクエリは、BigQuery Data Transfer Service の機能を使用しますが、このクエリは転送ではなく、読み込みジョブの上限の対象ではありません。

エクスポート ジョブ

bq コマンドライン ツール、Google Cloud コンソール、またはエクスポート タイプ jobs.insert API メソッドを使用して BigQuery からデータをエクスポートするジョブには、次の上限が適用されます。

上限 デフォルト 注
1 日にエクスポートされる最大バイト数 50 TiB 共有スロットプールを使用して、プロジェクトから 1 日あたり最大 50 TiB（テビバイト）のデータを無料でエクスポートできます。エクスポートしたバイト数の通知を提供する Cloud Monitoring アラート ポリシーを設定できます。 1 日あたり 50 TiB（テビバイト）を超えるデータをエクスポートするには、次のいずれかを行います。
1 日あたりのエクスポート ジョブの最大数 100,000 個のエクスポート プロジェクトで 1 日あたり最大 100,000 件のエクスポートを実行できます。1 日あたり 100,000 件を超えるエクスポートを実行するには、次のいずれかを行います。
1 つのファイルにエクスポートされる最大テーブルサイズ 1 GB 1 つのファイルに最大 1 GB のテーブルデータをエクスポートできます。1 GB を超えるデータをエクスポートするには、ワイルドカードを使用して複数のファイルにデータをエクスポートします。データを複数のファイルにエクスポートすると、さまざまなサイズのファイルになります。出力ファイルのサイズが 1 GB を超える場合もあります。
エクスポートあたりのワイルドカード URI 500 個の URI エクスポートには、最大 500 個のワイルドカード URI を含めることができます。

現在のエクスポート ジョブの使用状況を確認する方法について詳しくは、現在の割り当て使用量を確認するをご覧ください。

読み込みジョブ

Google Cloud コンソール、bq コマンドライン ツール、または読み込みタイプの jobs.insert API メソッドを使用して BigQuery にデータを読み込む場合、次の上限が適用されます。

上限 デフォルト 注
1 日のテーブルあたりの読み込みジョブ数 1,500 個のジョブ 読み込みジョブ（失敗した読み込みジョブを含む）は、宛先テーブルでの 1 日あたりのテーブル オペレーションの上限にカウントされます。標準テーブルとパーティション分割テーブルの 1 日あたりのテーブル オペレーション数の上限については、テーブルをご覧ください。
1 日あたりの読み込みジョブ 100,000 ジョブ プロジェクトは、24 時間ごとに最大 100,000 個の読み込みジョブの割り当てを補充します。読み込みに失敗したジョブは、この上限にカウントされます。前日の割り当てが一部使用されていない場合、24 時間で 100,000 件以上の読み込みジョブを実行できる場合があります。
テーブルあたりの最大列数 10,000 列 テーブルには最大 10,000 列を含めることができます。
読み込みジョブあたりの最大サイズ 15 TB CSV、JSON、Avro、Parquet、ORC の各入力ファイルの合計サイズは 15 TB 以下にする必要があります。
ジョブ構成でのソース URI の最大数 10,000 個の URI 1 つのジョブ構成に最大 10,000 個のソース URI を含めることができます。
読み込みジョブあたりの最大ファイル数 10,000,000 個のファイル 読み込みジョブには合計 1,000 万個のファイルを含めることができます（この数には、ワイルドカード URI に一致するファイルも含まれます）。
ソース Cloud Storage バケット内のファイルの最大数 約 60,000,000 個のファイル 読み込みジョブは、最大約 60,000,000 個のファイルを含む Cloud Storage バケットから読み取ることができます。
読み込みジョブの実行時間の上限 6 時間 6 時間を超えて実行されると、読み込みジョブは失敗します。
Avro: ファイルデータ ブロックの最大サイズ 16 MB Avro ファイルデータ ブロックのサイズの上限は 16 MB です。
CSV: 最大セルサイズ 100 MB CSV セルの最大サイズは 100 MB です。
CSV: 行の最大サイズ 100 MB CSV 行の最大サイズは 100 MB です。
CSV: 最大ファイルサイズ - 圧縮 4 GB 圧縮 CSV ファイルのサイズの上限は 4 GB です。
CSV: 最大ファイルサイズ - 非圧縮 5 TB 非圧縮 CSV ファイルのサイズの上限は 5 TB です。
改行区切りの JSON（ndJSON）: 行の最大サイズ 100 MB ndJSON 行のサイズは最大 100 MB です。
ndJSON: 最大ファイルサイズ - 圧縮 4 GB 圧縮 ndJSON ファイルのサイズの上限は 4 GB です。
ndJSON: 最大ファイルサイズ - 非圧縮 5 TB 非圧縮 ndJSON ファイルのサイズの上限は 5 TB です。

頻繁に更新され、読み込みジョブの制限を定期的に超える場合は、BigQuery へのデータのストリーミングを検討してください。

現在の読み込みジョブの使用状況を確認する方法については、現在の割り当て使用量を確認するをご覧ください。

BigQuery Data Transfer Service の読み込みジョブの割り当てに関する考慮事項

BigQuery Data Transfer Service の転送によって作成された読み込みジョブは、読み込みジョブに対する BigQuery の割り当てに含まれます。転送やその他の読み込みジョブで quotaExceeded エラーが発生しないようにするには、各プロジェクトで有効にする転送の数を検討することが重要です。

転送で必要な読み込みジョブの数を見積もるには、次の式を使用できます。

Number of daily jobs = Number of transfers x Number of tables x Schedule frequency x Refresh window

ここで

  • Number of transfers は、プロジェクトで有効にする転送構成の数です。

  • Number of tables は、特定の転送タイプごとに作成されるテーブルの数です。テーブルの数は転送タイプによって異なります。

    • キャンペーン マネージャーの転送では、約 25 個のテーブルが作成されます。
    • Google 広告の転送では、約 60 個のテーブルが作成されます。
    • Google アド マネージャーの転送では、約 40 個のテーブルが作成されます。
    • Google Play の転送では、約 25 個のテーブルが作成されます。
    • 検索広告 360 の転送では、約 50 個のテーブルが作成されます。
    • YouTube の転送では、約 50 個のテーブルが作成されます。

  • Schedule frequency は転送の実行頻度を示します。転送実行スケジュールは転送タイプごとに指定します。

  • Refresh window は、データ移転に含める日数です。1 を入力すると、毎日のバックフィルはありません。

コピージョブ

テーブルのコピーに関する BigQuery ジョブ（標準テーブル、テーブル クローン、テーブル スナップショットのコピー、クローン、スナップショットを作成するジョブなど）には、次の上限が適用されます。 これらの上限は、Google Cloud コンソール、bq コマンドライン ツール、またはジョブ構成で copy フィールドを指定した jobs.insert メソッドを使用して作成されたジョブに適用されます。コピージョブは、そのジョブが成功するか失敗するかにかかわらず、これらの上限にカウントされます。

上限 デフォルト 注
宛先テーブルごとの 1 日あたりコピージョブ数 1 日のテーブル オペレーションをご覧ください。
1 日あたりのコピージョブ数 100,000 ジョブ 1 日あたりプロジェクトで最大 100,000 個のコピージョブを実行できます。
宛先テーブルあたりの 1 日のリージョン間コピージョブの数 100 ジョブ プロジェクトでは、宛先テーブルに対して 1 日あたり 100 個までのリージョン間コピージョブを実行できます。
1 日あたりのリージョン間コピージョブ 2,000 ジョブ プロジェクトで 1 日あたり最大 2,000 件のリージョン間コピージョブを実行できます。
コピーするコピー元テーブルの数 1,200 個のコピー元テーブル コピージョブごとに最大 1,200 個のコピー元テーブルからコピーできます。

現在のコピージョブの使用状況を確認する方法については、コピージョブ - 現在の割り当て使用量を確認するをご覧ください。

データセットのコピーには、以下の上限が適用されます。

上限 デフォルト 注
コピー元データセット内の最大テーブル数 20,000 個のテーブル コピー元データセットには、最大 20,000 個のテーブルを含めることができます。
実行ごとに同じリージョン内の宛先データセットにコピーできる最大テーブル数 20,000 個のテーブル プロジェクトでは、同じリージョンにある宛先データセットに、実行あたり 20,000 個のテーブルをコピーできます。
実行間で別のリージョンの宛先データセットにコピーできる最大テーブル数 1,000 個のテーブル 実行ごとに 1,000 個のテーブルを異なるリージョンの宛先データセットにコピーできます。8,000 個のテーブルを含むデータセットのリージョン間コピーを構成すると、BigQuery Data Transfer Service により 8 個の実行単位が順次自動的に作成されます。最初の実行で 1,000 個のテーブルがコピーされます。24 時間後の 2 回目の実行で 1,000 個のテーブルがコピーされます。このプロセスは、データセット内のすべてのテーブルがコピーされるまで（データセットあたり最大 20,000 個のテーブルがコピーされるまで）継続されます。

予約

予約には、次の割り当てが適用されます。

割り当て デフォルト 注
EU リージョンのスロットの合計数 5,000 スロット Google Cloud コンソールを使用して EU マルチリージョンで購入できる BigQuery スロットの最大数。
Google Cloud コンソールで割り当てを表示する
米国リージョンのスロットの合計数 10,000 スロット Google Cloud コンソールを使用して米国マルチリージョンで購入できる BigQuery スロットの最大数。
Google Cloud コンソールで割り当てを表示する
us-east1 リージョンのスロットの合計数 4,000 スロット Google Cloud コンソールを使用して、リストされたリージョンで購入できる BigQuery スロットの最大数。
Google Cloud コンソールで割り当てを表示する
次のリージョンのスロットの合計数:
  • asia-south1
  • asia-southeast1
  • europe-west2
  • us-central1
  • us-west1
 2,000 スロット Google Cloud コンソールを使用して、リストされた各リージョンで購入できる BigQuery スロットの最大数。
Google Cloud コンソールで割り当てを表示する
次のリージョンのスロットの合計数:
  • asia-east1
  • asia-northeast1
  • asia-northeast3
  • asia-southeast2
  • australia-southeast1
  • europe-north1
  • europe-west1
  • europe-west3
  • europe-west4
  • northamerica-northeast1
  • us-east4
  • southamerica-east1
 1,000 スロット Google Cloud コンソールを使用して、一覧表示された各リージョンで購入できる BigQuery スロットの最大数。
Google Cloud コンソールで割り当てを表示する
BigQuery Omni リージョンのスロットの合計数 100 スロット Google Cloud コンソールを使用して、BigQuery Omni リージョンで購入できる BigQuery スロットの最大数。
Google Cloud コンソールで割り当てを表示する
他のすべてのリージョンのスロット合計数 500 スロット Google Cloud コンソールを使用して各リージョンで購入可能な BigQuery スロットの最大数。
Google Cloud コンソールで割り当てを表示する

予約には次の上限が適用されます。

上限 値 注
スロット予約の管理プロジェクトの数 組織あたり 5 プロジェクト 特定のロケーション / リージョンでスロットに対して予約または有効なコミットメントを含めることができる組織内のプロジェクトの最大数。
Standard エディションの予約の最大数 プロジェクトごとに 10 件の予約 特定のロケーション / リージョンにおける、組織内の管理プロジェクトごとの Standard エディションの予約の最大数。
Enterprise または Enterprise Plus エディションの予約の最大数 プロジェクトごとに 200 件の予約 特定のロケーション / リージョンにおける、組織内の管理プロジェクトごとの Enterprise または Enterprise Plus エディションの予約の最大数。
CONTINUOUS ジョブタイプの予約割り当てに関連付けられている予約のスロットの最大数。 500 スロット CONTINUOUS ジョブタイプの予約割り当てを作成する場合は、関連する予約のスロットが 500 を超えないようにしてください。

データセット

BigQuery データセットには、次の上限が適用されます。

上限 デフォルト 注
データセットの最大数 無制限 1 つのプロジェクトで保持できるデータセットの数に上限はありません。
データセットあたりのテーブル数 無制限 API 呼び出しを使用する場合、データセット内のテーブル数が 50,000 件に近づくと、列挙のパフォーマンスが低下します。Google Cloud コンソールでは、データセットごとに最大 50,000 個のテーブルを表示できます。
データセットのアクセス制御リストの承認済みリソースの数 2,500 個のリソース データセットのアクセス制御リストには、合計最大 2,500 個の承認済みリソースを含めることができます。これには、承認済みビュー、承認済みデータセット、承認済み関数が含まれます。多数の承認済みビューが原因でこの上限を超える場合は、承認済みデータセットにビューをグループ化することを検討してください。
10 秒ごとのデータセットあたりデータセット更新オペレーションの数 5 個のオペレーション プロジェクトでは、10 秒ごとに最大 5 個のデータセット更新オペレーションを行うことができます。データセットの更新制限には、以下によって実行されるすべてのメタデータ更新オペレーションが含まれます。
データセットの説明の最大長 16,384 文字 データセットに説明を追加する場合、テキストは 16,384 文字以下で入力してください。

テーブル

すべてのテーブル

すべての BigQuery テーブルに次の上限が適用されます。

上限 デフォルト 注
列名の最大長 300 文字 列名は 300 文字以下にする必要があります。
列の説明の最大文字数 1,024 文字 列に説明を追加する場合、テキストの文字数は 1,024 文字以下にしてください。
ネストされたレコードの最大深度 15 レベル RECORD 型の列には、ネストされた RECORD 型（子レコードとも呼ばれる）を含めることができます。ネストの深さは最大 15 レベルに制限されます。この上限は、レコードがスカラーか配列ベース（繰り返し）かに依存しません。

標準テーブル

BigQuery の標準（組み込み）テーブルには、次の上限が適用されます。

上限 デフォルト 注
1 日あたりのテーブル変更 1,500 件の変更

プロジェクトでは、データの追加、データの更新、テーブルの切り捨てなど変更内容にかかわらず、1 日あたりテーブルごとに最大 1,500 件のテーブル変更を行うことができます。この上限は変更できず、宛先テーブルを追加または上書きする読み込みジョブ、コピージョブ、クエリジョブすべてを合わせた合計が含まれます。

DML ステートメントは 1 日あたりのテーブル変更の数にカウントされません。

ストリーミング データは 1 日あたりのテーブル変更の数にカウントされません。
テーブルあたりのテーブル メタデータ更新オペレーションの最大レート 10 秒あたり 5 個のオペレーション プロジェクトで、テーブルごとに 10 秒あたり最大 5 個のテーブル メタデータ更新オペレーションを実行できます。この上限は、以下によって実行されるすべてのテーブル メタデータ更新オペレーションに適用されます。
  • Google Cloud コンソール
  • bq コマンドライン ツール
  • BigQuery クライアント ライブラリ
  • 次の API メソッド:
  • テーブルに対する DDL ステートメント
この上限には、宛先テーブルを追加または上書きする、または、DML DELETE、INSERT、MERGE、TRUNCATE TABLE または UPDATE ステートメントを使用してテーブルにデータを書き込む、読み込みジョブ、コピージョブ、クエリジョブすべてを合わせた合計も含まれます。DML ステートメントはこの上限までカウントされますが、上限に達しても、その対象にはなりません。DML オペレーションには、専用のレート制限があります。

この上限を超えると、Exceeded rate limits: too many table update operations for this table のようなエラー メッセージが表示されます。このエラーは一時的なものです。指数バックオフで再試行できます。

この上限にカウントされるオペレーションは、ログで確認できます。このエラーの診断と解決については、割り当てエラーのトラブルシューティングをご覧ください。
テーブルあたりの最大列数 10,000 列 テーブル、クエリ結果、ビュー定義に、それぞれ最大 10,000 列を含めることができます。

外部テーブル

データが Parquet、ORC、Avro、CSV、または JSON 形式で Cloud Storage に保存される BigQuery テーブルには、次の上限が適用されます。

上限 デフォルト 注
外部テーブルごとのソース URI の最大数 10,000 個の URI 各外部テーブルには最大 10,000 個のソース URI を含めることができます。
外部テーブルごとのファイルの最大数 10,000,000 個のファイル 外部テーブルには最大 1,000 万個のファイルを含めることができます。これには、すべてのワイルドカード URI に一致するファイルが含まれます。
外部テーブルごとの Cloud Storage に格納されるデータの最大サイズ 600 TB 外部テーブルの入力ファイルの合計サイズは最大 600 テラバイトまでです。この上限は、Cloud Storage に保存されているファイルサイズに適用されます（このサイズはクエリの料金設定式で使用されるサイズとは異なります）。外部のパーティション分割テーブルの場合、この上限はパーティションのプルーニング後に適用されます。
ソース Cloud Storage バケット内のファイルの最大数 約 60,000,000 個のファイル 外部テーブルは、最大約 60,000,000 個のファイルを含む Cloud Storage バケットを参照できます。外部のパーティション分割テーブルの場合、この上限はパーティションのプルーニング前に適用されます。

パーティション分割テーブル

BigQuery パーティション分割テーブルには、次の上限が適用されます。

パーティションの上限は、宛先パーティションへのデータの追加や上書きを実行するすべての読み込みジョブ、コピージョブ、クエリジョブを合わせた合計に適用されます。

1 つのジョブが複数のパーティションに影響することがあります。たとえば、クエリジョブと読み込みジョブは複数のパーティションに書き込むことができます。

BigQuery では、ジョブで消費される上限を決定する際に、ジョブの対象であるパーティションの数を使用します。ストリーミング挿入はこの上限に影響しません。

パーティション分割テーブルの制限内に収める方法については、割り当てエラーのトラブルシューティングをご覧ください。

上限 デフォルト 注
パーティション分割テーブルあたりのパーティション数 10,000 パーティション 各パーティション分割テーブルには、最大 10,000 個のパーティションを設定できます。この上限を超える場合は、パーティショニングに加えて、またはパーティショニングの代わりにクラスタリングを使用することを検討してください。
1 つのジョブで変更されるパーティションの数 4,000 個のパーティション 1 つのジョブ オペレーション（クエリまたは読み込み）で処理できるパーティションの数は最大 4,000 です。BigQuery では、4,000 個を超えるパーティションを変更しようとするクエリまたは読み込みジョブは拒否されます。
1 日の取り込み時間パーティション分割テーブルあたりのパーティションの変更回数 5,000 回の変更

プロジェクトは、データの追加、データの更新、取り込み時間パーティション分割テーブルの切り捨てなど変更内容にかかわらず、1 日あたり最大 5,000 件のパーティション変更を行うことができます。

DML ステートメントは 1 日あたりのパーティション変更の数にカウントされません。

1 日の列パーティション分割テーブルあたりのパーティション変更数 30,000 回の変更

プロジェクトで、列パーティション分割テーブルに対して 1 日あたり最大 30,000 回のパーティション変更を行うことができます。

DML ステートメントは 1 日あたりのパーティション変更の数にカウントされません。

ストリーミング データは 1 日あたりのパーティション変更の数にカウントされません。
パーティション分割テーブルあたりのテーブル メタデータ更新オペレーションの最大レート 10 秒あたり 50 件の変更 プロジェクトでは、10 秒ごとに最大 50 件の変更をパーティション分割テーブルごとに実行できます。この上限は、以下によって実行されるすべてのパーティション分割テーブル メタデータ更新オペレーションに適用されます。
  • Google Cloud コンソール
  • bq コマンドライン ツール
  • BigQuery クライアント ライブラリ
  • 次の API メソッド:
  • テーブルに対する DDL ステートメント
この上限には、宛先テーブルを追加または上書きする、または、DML DELETE、INSERT、MERGE、TRUNCATE TABLE または UPDATE ステートメントを使用してテーブルにデータを書き込む、読み込みジョブ、コピージョブ、クエリジョブすべてを合わせた合計も含まれます。

この上限を超えると、Exceeded rate limits: too many partitioned table update operations for this table のようなエラー メッセージが表示されます。このエラーは一時的なものです。指数バックオフで再試行できます。

この上限にカウントされるオペレーションは、ログで確認できます。
範囲パーティショニングが可能な範囲数 10,000 個の範囲 範囲パーティション分割テーブルには、最大 10,000 個の範囲を設定できます。この上限は、テーブルの作成時にパーティションの設定に適用されます。この上限は、テーブルの作成後に実際のパーティション数にも適用されます。

テーブル クローン

BigQuery のテーブル クローンには、次の上限が適用されます。

上限 デフォルト 注
チェーン内のクローンとスナップショットの最大数 3 つのテーブル クローンまたはスナップショット クローンとスナップショットの組み合わせの深さは 3 に制限されます。ベーステーブルのクローンまたはスナップショットを実行する場合、さらに 2 回しか結果のクローンまたはスナップショットを実行できません。3 回目にクローンまたはスナップショットを実行しようとすると、エラーが発生します。たとえば、ベーステーブルのクローン A、クローン A のスナップショット B、スナップショット B のクローン C を作成できます。第 3 レベルのクローンまたはスナップショットをさらに複製するには、代わりにコピー オペレーションを使用します。
ベーステーブルのクローンとスナップショットの最大数 1,000 個のテーブル クローンまたはスナップショット 特定のベーステーブルを合わせた既存のクローンとスナップショットは 1,000 個までしか作成できません。たとえば、600 個のスナップショットと 400 個のクローンがある場合、この上限に達しています。

テーブル スナップショット

BigQuery のテーブル スナップショットには、次の上限が適用されます。

上限 デフォルト 注
同時テーブル スナップショット ジョブの最大数 100 ジョブ プロジェクトで最大 100 個のテーブル スナップショット ジョブを同時に実行できます。
1 日あたりのテーブル スナップショット ジョブの最大数 50,000 ジョブ プロジェクトで、1 日に最大 50,000 個のテーブル スナップショット ジョブを実行できます。
1 日あたりのテーブルごとのテーブル スナップショット ジョブの最大数 50 ジョブ プロジェクトでは、テーブルごとに 1 日あたり最大 50 件のテーブル スナップショット ジョブを実行できます。
10 秒間のテーブル スナップショットごとのメタデータ更新の最大数。 5 回の更新 プロジェクトで、テーブル スナップショットのメタデータを 10 秒ごとに最大 5 回まで更新できます。
チェーン内のクローンとスナップショットの最大数 3 つのテーブル クローンまたはスナップショット クローンとスナップショットの組み合わせの深さは 3 に制限されます。ベーステーブルのクローンまたはスナップショットを実行する場合、さらに 2 回しか結果のクローンまたはスナップショットを実行できません。3 回目にクローンまたはスナップショットを実行しようとすると、エラーが発生します。たとえば、ベーステーブルのクローン A、クローン A のスナップショット B、スナップショット B のクローン C を作成できます。第 3 レベルのクローンまたはスナップショットをさらに複製するには、代わりにコピー オペレーションを使用します。
ベーステーブルのクローンとスナップショットの最大数 1,000 個のテーブル クローンまたはスナップショット 特定のベーステーブルを合わせた既存のクローンとスナップショットは 1,000 個までしか作成できません。たとえば、600 個のスナップショットと 400 個のクローンがある場合、この上限に達しています。

ビュー

ビューとマテリアライズド ビューには、次の割り当てと上限が適用されます。

論理ビュー

BigQuery 標準ビューには次の上限が適用されます。

上限 デフォルト 注
ネストされたビューレベルの最大数 16 レベル BigQuery は最大 16 レベルまでのネストビューをサポートします。この上限までビューを作成することは可能ですが、クエリは 15 レベルに制限されます。上限を超えると、BigQuery は INVALID_INPUT エラーを返します。
ビューの定義に使用される GoogleSQL クエリの最大長 256 K 文字 ビューを定義する単一の GoogleSQL クエリの長さは、最大 256 K 文字です。この上限は単一のクエリに適用されます。クエリで参照されるビューの長さは含まれません。
データセットあたりの承認済みビューの最大数 データセットをご覧ください。

マテリアライズド ビュー

BigQuery のマテリアライズド ビューには、次の上限が適用されます。

上限 デフォルト 注
ベーステーブルの参照（同じデータセット） 20 個のマテリアライズド ビュー 各ベーステーブルは、同じデータセットから最大 20 個のマテリアライズド ビューで参照できます。
ベーステーブルの参照（同じプロジェクト） 100 個のマテリアライズド ビュー 各ベーステーブルは、同じプロジェクトから最大 100 個のマテリアライズド ビューで参照できます。
ベーステーブルの参照（組織全体） 500 個のマテリアライズド ビュー 各ベーステーブルは、組織全体から最大 500 個のマテリアライズド ビューから参照できます。
データセットあたりの承認済みビューの最大数 データセットをご覧ください。

検索インデックス

BigQuery 検索インデックスには次の上限が適用されます。

上限 デフォルト 注
1 プロジェクト、1 リージョン、1 日あたりの CREATE INDEX DDL ステートメントの数 500 件のオペレーション プロジェクトでは、毎日 1 つのリージョン内で最大 500 件の CREATE INDEX DDL オペレーションを発行できます。
テーブルごとの 1 日あたりの検索インデックス DDL ステートメントの数 20 件のオペレーション プロジェクトでは、1 日あたりテーブルごとに最大 20 件の CREATE INDEX または DROP INDEX DDL オペレーションを発行できます。
予約で実行されない検索インデックス作成が許可される組織ごとのテーブルデータの最大サイズ マルチリージョンで 100 TB。他のすべてのリージョンで 20 TB 組織のインデックスを持つテーブルの全体的なサイズが、リージョンの上限（US と EU のマルチリージョンで 100 TB。その他すべてのリージョンで 20 TB）を下回った場合、テーブルの検索インデックスを作成できます。インデックス管理ジョブが独自の予約で実行される場合、この上限は適用されません。

ベクトル インデックス

BigQuery ベクトル インデックスには、次の上限が適用されます。

上限 デフォルト 注
ベーステーブルの最小行数 5,000 行 ベクトル インデックスを作成するには、テーブルに少なくとも 5,000 行が必要です。
ベーステーブルの最大行数 インデックス タイプが IVF の場合は 10,000,000,000 行

インデックス タイプが TREE_AH の場合は 200,000,000 行		 IVF ベクトル インデックスを作成するには、1 つのテーブルに最大 10,000,000,000 行まで含めることができます。TREE_AH ベクトル インデックスを作成する場合は、200,000,000 行まで含めることができます。
インデックス登録する列内の配列の最大サイズ 1,600 要素 インデックス登録する列の配列内の要素は最大 1,600 個です。
ベクトル インデックスにデータを挿入するテーブルの最小サイズ 10 MB 10 MB 未満のテーブルに対してベクトル インデックスを作成すると、そのインデックスにはデータが挿入されません。同様に、ベクトル インデックス登録されたテーブルからデータを削除してテーブルサイズが 10 MB を下回るようになった場合、ベクトル インデックスは一時的に無効になります。この現象は、インデックス管理ジョブに独自の予約を使用するかどうかに関係なく発生します。ベクトル インデックス登録されたテーブルのサイズが再び 10 MB を超えると、インデックスに自動的にデータが挿入されます。
1 プロジェクト、1 リージョン、1 日あたりの CREATE VECTOR INDEX DDL ステートメントの数 500 件のオペレーション 各プロジェクトで、リージョンごとに 1 日あたり最大 500 件の CREATE VECTOR INDEX DDL オペレーションを発行できます。
テーブルごとの 1 日あたりのベクトル インデックス DDL ステートメントの数 10 件のオペレーション テーブルごとに 1 日あたり最大 10 件の CREATE VECTOR INDEX オペレーションまたは DROP VECTOR INDEX オペレーションを発行できます。
予約で実行されないベクトル インデックス作成が許可される組織ごとのテーブルデータの最大サイズ 6 TB 組織のインデックスを持つテーブルの合計サイズが 6 TB を下回った場合、テーブルのベクトル インデックスを作成できます。インデックス管理ジョブが独自の予約で実行される場合、この上限は適用されません。

ルーティン

ルーティンには、次の割り当てと上限が適用されます。

ユーザー定義の関数

GoogleSQL クエリに含まれる一時的および永続的なユーザー定義関数（UDF）には、次の上限が適用されます。

上限 デフォルト 注
1 行あたりの最大出力 5 MB 単一行の処理時に JavaScript UDF が出力できるデータの最大量は約 5 MB です。
JavaScript UDF を使用した同時実行レガシー SQL クエリの最大数 6 個のクエリ プロジェクトには、JavaScript で UDF を含むレガシー SQL クエリを同時に 6 個まで設定できます。この制限には、インタラクティブ クエリとバッチクエリの両方が含まれます。この上限は GoogleSQL クエリには適用されません。
クエリあたりの JavaScript UDF リソースの最大数 50 個のリソース クエリジョブには、インライン コード blob や外部ファイルなど、最大 50 個の JavaScript UDF リソースを含めることができます。
インライン コード blob の最大サイズ 32 KB UDF のインライン コード blob の最大サイズは 32 KB です。
各外部コードリソースの最大サイズ 1 MB 各 JavaScript コードリソースの最大サイズは 1 MB です。

永続的な UDF には次の上限が適用されます。

上限 デフォルト 注
UDF 名の最大文字数 256 文字 UDF 名の最大文字数は 256 文字です。
引数の最大数 256 個の引数 UDF には最大 256 個の引数を指定できます。
引数名の最大文字数 128 文字 UDF の引数名は最大 128 文字です。
UDF 参照チェーンの最大深度 16 個の参照 UDF 参照チェーンは、最大 16 個の参照深度にできます。
STRUCT 型の引数または出力の最大深度 15 レベル STRUCT 型の UDF 引数または出力の最大深度は 15 です。
UDF あたりの STRUCT 型の引数または出力の最大フィールド数 1,024 フィールド UDF の STRUCT 型の引数と出力には、最大 1,024 個のフィールドを指定できます。
CREATE FUNCTION ステートメント内の JavaScript ライブラリの最大数 50 ライブラリ CREATE FUNCTION ステートメントには、最大 50 個の JavaScript ライブラリを含めることができます。
含まれる JavaScript ライブラリパスの最大文字数 5,000 文字 UDF に含まれる JavaScript ライブラリパスの最大文字数は 5,000 文字です。
10 秒間の UDF あたりの最大更新レート 5 回の更新 プロジェクトで 10 秒ごとに最大 5 回まで UDF を更新できます。
データセットあたりの承認済み UDF の最大数 データセットをご覧ください。

リモート関数

BigQuery のリモート関数には、次の上限が適用されます。

上限 デフォルト 注
リモート関数を含む同時実行クエリの最大数 10 件のクエリ プロジェクトごとにリモート関数を使用して最大 10 個のクエリを同時に実行できます。
最大入力サイズ 5 MB 1 つの行のすべての入力引数の最大合計サイズは 5 MB です。
HTTP レスポンス サイズの上限（Cloud Run functions 第 1 世代） 10 MB Cloud Run 関数第 1 世代の HTTP レスポンス本文の上限は 10 MB です。この値を超えると、クエリが失敗します。
HTTP レスポンス サイズの上限（Cloud Run functions 第 2 世代または Cloud Run） 15 MB Cloud Run 関数第 2 世代または Cloud Run からの HTTP レスポンス本文の上限は 15 MB です。この値を超えると、クエリが失敗します。
最大 HTTP 呼び出し時間上限（Cloud Run functions 第 1 世代） 9 分 Cloud Run 関数第 1 世代には、個々の HTTP 呼び出しに独自の制限時間を設定できますが、最大制限時間は 9 分です。Cloud Run 関数第 1 世代に設定された制限時間を超えると、HTTP 呼び出しとクエリが失敗することがあります。
HTTP 呼び出しの制限時間（Cloud Run functions 第 2 世代または Cloud Run） 20 分 Cloud Run 関数第 2 世代または Cloud Run への個々の HTTP 呼び出しの制限時間。この値を超えると、HTTP 呼び出しとクエリが失敗することがあります。
HTTP 呼び出しの再試行の最大回数 20 Cloud Run 関数第 1 世代、第 2 世代、または Cloud Run への個々の HTTP 呼び出しの最大再試行回数。この値を超えると、HTTP 呼び出しとクエリが失敗することがあります。

テーブル関数

BigQuery のテーブル関数には、次の上限が適用されます。

上限 デフォルト 注
テーブル関数名の最大文字数 256 文字 テーブル関数名は 256 文字まで指定できます。
引数名の最大文字数 128 文字 テーブル関数の引数名の長さは最大 128 文字です。
引数の最大数 256 個の引数 テーブル関数には最大 256 個の引数を指定できます。
テーブル関数の参照チェーンの最大深度 16 個の参照 テーブル関数参照チェーンは最大 16 個の参照レベルにできます。
STRUCT 型の引数または出力の最大深度 15 レベル テーブル関数の STRUCT 引数の最大深度は 15 レベルです。同様に、テーブル関数の出力に含まれる STRUCT レコードの最大深度は 15 レベルです。
STRUCT 型の引数または戻りテーブルに含まれるフィールドのテーブル関数あたりの最大数 1,024 フィールド テーブル関数の STRUCT 引数には、最大 1,024 個のフィールドを指定できます。同様に、テーブル関数の出力に含まれる STRUCT レコードには、最大 1,024 個のフィールドを含めることができます。
戻りテーブルの列の最大数 1,024 列 テーブル関数によって返されるテーブルには、最大 1,024 個の列を設定できます。
戻りテーブルの列名の最大文字数 128 文字 返されるテーブルの列名は最大 128 文字です。
10 秒あたりのテーブル関数ごとの更新の最大数 5 回の更新 プロジェクトで、テーブル関数を 10 秒ごとに最大 5 回まで更新できます。

Apache Spark でのストアド プロシージャ

Apache Spark 用 BigQuery ストアド プロシージャには、次の上限が適用されます。

上限 デフォルト 注
ストアド プロシージャの同時実行クエリの最大数 50 プロジェクトごとに、最大 50 回のストアド プロシージャ クエリを同時に実行できます。
使用中の CPU の最大数 12,000 プロジェクトごとに最大 12,000 の CPU を使用できます。すでに処理されているクエリはこの上限を消費しません。

ロケーションごとに、最大 2,400 の CPU を使用できます。ただし、以下のロケーションを除きます。

  • asia-south2
  • australia-southeast2
  • europe-central2
  • europe-west8
  • northamerica-northeast2
  • southamerica-west1

これらのロケーションでは、プロジェクトごとに各ロケーションに最大 500 の同時 CPU を使用できます。

同じ地理的エリアにあるマルチリージョン ロケーションと単一リージョン ロケーションで同時にクエリを実行すると、クエリで同じ同時 CPU 割り当てが消費される可能性があります。
使用中の標準永続ディスクの最大合計サイズ 204.8 TB

各プロジェクトのロケーションごとに最大 204.8 TB の標準永続ディスクを使用できます。すでに処理されているクエリはこの上限を消費しません。

同じ地理的エリアにあるマルチリージョン ロケーションと単一リージョン ロケーションで同時にクエリを実行すると、クエリで同じ標準永続ディスク割り当てが消費される可能性があります。

Notebooks

すべての Dataform の割り当てと上限と Colab Enterprise の割り当てと上限は、BigQuery のノートブックをご覧ください。次の上限も適用されます。

上限 デフォルト 注
ノートブックの最大サイズ 20 MB

ノートブックのサイズは、コンテンツ、メタデータ、エンコードのオーバーヘッドの合計です。

ノートブックのコンテンツのサイズを確認するには、ノートブックのヘッダーを展開し、[ビュー] をクリックしてから [ノートブック情報] をクリックします。
Dataform への 1 秒あたりのリクエストの最大数 100 Notebooks は、Dataform を使用して作成および管理されます。ノートブックを作成または変更するアクションも、この割り当てにカウントされます。この割り当ては、保存したクエリと共有されます。たとえば、1 秒以内にノートブックに 50 件の変更と、保存されたクエリに 50 件の変更を行った場合は、この割り当てに達します。

保存済みクエリ

すべての Dataform の割り当てと上限が保存済みクエリに適用されます。次の上限も適用されます。

上限 デフォルト 注
保存したクエリの最大サイズ 10 MB
Dataform への 1 秒あたりのリクエストの最大数 100 保存したクエリは、Dataform を使用して作成および管理されます。 保存したクエリを作成または変更するアクションは、この割り当てに対してカウントされます。この割り当てはノートブックと共有されます。たとえば、1 秒以内にノートブックに 50 件の変更と、保存されたクエリに 50 件の変更を行った場合は、この割り当てに達します。

データ操作言語

BigQuery のデータ操作言語（DML）ステートメントには、次の上限が適用されます。

上限 デフォルト 注
1 日あたりの DML ステートメント数 無制限 1 日にプロジェクトで実行できる DML ステートメントの数に制限はありません。

DML ステートメントは、1 日あたりのテーブル変更回数、またはパーティション分割テーブルの場合、1 日あたりのパーティション分割テーブルの変更回数にカウントされません。

DML ステートメントには、注意すべき次の制限事項があります。
1 日あたりのテーブルごとの同時 DML ステートメント数（INSERT） 1,500 件のステートメント 最初の 1,500 件の INSERT ステートメントは、送信された直後に実行されます。この上限に達すると、テーブルに書き込む INSERT ステートメントの同時実行数は 10 件に制限されます。それ以上の INSERT ステートメントは PENDING キューに追加されます。一度に最大で 100 件の INSERT ステートメントをテーブルに対してキューに入れることができます。ある INSERT ステートメントが完了すると、次の INSERT ステートメントがキューから除かれて実行されます。

DML の INSERT ステートメントをより頻繁に実行する必要がある場合は、Storage Write API を使用してテーブルにデータをストリーミングすることを検討してください。
テーブルごとの同時変更 DML ステートメント 2 個のステートメント BigQuery では、テーブルごとに最大 2 個の同時変更 DML ステートメント（UPDATE、DELETE、MERGE）が実行されます。テーブルに対する追加の変更 DML ステートメントはキューに入ります。
テーブルごとにキューに入る変更 DML ステートメント20 個のステートメント 1 つのテーブルつき、最大 20 個の変更 DML ステートメントを実行待ちのキューに入れることができます。テーブルに追加の変更 DML ステートメントを送信すると、これらのステートメントは失敗します。
DML ステートメントの最大キュー時間 6 時間 インタラクティブの優先 DML ステートメントは、キューで最大 6 時間待機できます。6 時間が経過しても実行されない場合、ステートメントは失敗します。
各テーブルに対する DML ステートメントの最大レート 10 秒ごとに 25 個のステートメント プロジェクトでは、各テーブルに対して 10 秒ごとに最大 25 個の DML ステートメントを実行できます。INSERT と変更 DML ステートメントの両方がこの上限に影響します。

変更 DML ステートメントの詳細については、INSERT DML の同時実行と UPDATE, DELETE, MERGE DML の同時実行をご覧ください。

複数ステートメント クエリ

BigQuery の複数ステートメント クエリには、次の上限が適用されます。

上限 デフォルト 注
同時実行の複数ステートメント クエリの最大数 1,000 件の複数ステートメント クエリ 1 つのプロジェクトで、最大 1,000 件のマルチステートメント クエリを同時に実行できます。
累積の上限時間 24 時間 複数ステートメント クエリの累積の上限時間は 24 時間です。
ステートメント時間の上限 6 時間 複数ステートメント クエリ内の個別のステートメント時間の上限は 6 時間です。

クエリ内の再帰 CTE

BigQuery の再帰共通テーブル式（CTE）には、次の上限が適用されます。

上限 デフォルト 注
イテレーションの上限 500 回のイテレーション 再帰 CTE では、イテレーションをこの回数まで実行できます。この上限を超えると、エラーが発生します。イテレーションの制限を回避する方法については、イテレーションの制限エラーのトラブルシューティングをご覧ください。

行レベルのセキュリティ

BigQuery の行レベルのアクセス ポリシーには次の上限が適用されます。

上限 デフォルト 注
テーブルごとの行アクセス ポリシーの最大数 400 個のポリシー テーブルでは、最大 400 個の行アクセス ポリシーを使用できます。
クエリごとの行アクセス ポリシーの最大数 6,000 個のポリシー 1 つのクエリで、最大 6,000 個の行アクセス ポリシーにアクセスできます。
10 秒あたりのポリシーごとの CREATE / DROP DDL ステートメントの最大数 5 個のステートメント 10 秒以内に、行アクセス ポリシー リソースごとに最大 5 つの CREATE または DROP ステートメントを作成できます。
10 秒あたりのテーブルごとの DROP ALL ROW ACCESS POLICIES ステートメント 5 個のステートメント プロジェクトで、10 秒以内にテーブルごとに最大 5 つの DROP ALL ROW ACCESS POLICIES ステートメントを作成できます。

データポリシー

列レベルの動的データ マスキングには、次の上限が適用されます。

上限 デフォルト 注
ポリシータグごとのデータポリシーの最大数。 ポリシータグごとに 8 個のポリシー ポリシータグごとに最大 8 個のデータポリシー。これらのポリシーのいずれかを列レベルのアクセス制御に使用できます。 重複するマスキング式はサポートされていません。

BigQuery ML

BigQuery ML には次の上限が適用されます。

クエリジョブ

BigQuery ML ステートメントと関数を使用する GoogleSQL クエリジョブには、クエリジョブの割り当てと上限がすべて適用されます。

CREATE MODEL ステートメント

CREATE MODEL ジョブには、次の上限が適用されます。

上限 デフォルト 注
各プロジェクトで 48 時間あたりの CREATE MODEL ステートメント クエリ 20,000 件のステートメント クエリ 一部のモデルは、独自にリソースと割り当ての管理を行う Vertex AI サービスを利用してトレーニングされます。
実行時間の上限 24 時間または 72 時間 CREATE MODEL ジョブのタイムアウトはデフォルトで 24 時間に設定されていますが、時系列、AutoML、ハイパーパラメータ チューニング ジョブは 72 時間でタイムアウトします。

Vertex AI と Cloud AI のサービス関数

Vertex AI 大規模言語モデル（LLM）と Cloud AI サービスを使用する関数には、次の上限が適用されます。

関数 1 分あたりのリクエスト数 1 ジョブあたりの行数 同時に実行されているジョブの数
ML.GENERATE_TEXT（gemini-1.5-pro モデルを介してリモートモデルを使用する場合） 60 21,600 5
ML.GENERATE_TEXT（gemini-1.5-flash モデルを介してリモートモデルを使用する場合） 200 72,000 5
ML.GENERATE_TEXT（us-central1 リージョンの gemini-1.0-pro-vision モデルを介してリモートモデルを使用する場合） 100 20,000 1
ML.GENERATE_TEXT（us-central1 以外のリージョンの gemini-1.0-pro-vision モデルを介してリモートモデルを使用する場合） 10 3,600 1
ML.GENERATE_TEXT（us-central1 リージョンの gemini-1.0-pro モデルを介してリモートモデルを使用する場合） 300 108,000 5
ML.GENERATE_TEXT（us-central1 以外のリージョンの gemini-1.0-pro モデルを介してリモートモデルを使用する場合） 10 3,600 5
ML.GENERATE_TEXT（Anthropic Claude モデルを介してリモートモデルを使用する場合） 30 10,800 5
ML.GENERATE_TEXT（text-bison モデルを介してリモートモデルを使用する場合） 1,600 576,000 5
ML.GENERATE_TEXT（text-bison-32 モデルを介してリモートモデルを使用する場合） 300 108,000 5
ML.GENERATE_EMBEDDING（サポートされているヨーロッパの単一リージョンの Vertex AI multimodalembedding モデルを介してリモートモデルと組み合わせて使用する場合） 120 14,000 5
ML.GENERATE_EMBEDDING（サポートされているヨーロッパの単一リージョン以外のリージョンの Vertex AI multimodalembedding モデルを介してリモートモデルと組み合わせて使用する場合） 600 25,000 5
ML.GENERATE_EMBEDDING（us-central1 リージョンの Vertex AI text-embedding モデルと text-multilingual-embedding モデルを介してリモートモデルと組み合わせて使用する場合） 1,500 2,700,000 1
ML.GENERATE_EMBEDDING（us-central1 以外のリージョンの Vertex AI text-embedding モデルと text-multilingual-embedding モデルを介してリモートモデルと組み合わせて使用する場合） 100 180,000 1
ML.PROCESS_DOCUMENT（ドキュメントの平均ページ数は 1 ページ） 600 150,000 5
ML.PROCESS_DOCUMENT（ドキュメントの平均ページ数は 10 ページ） 600 100,000 5
ML.PROCESS_DOCUMENT（ドキュメントの平均ページ数は 50 ページ） 600 15,000 5
ML.TRANSCRIBE 200 10,000 5
ML.ANNOTATE_IMAGE 1,800 648,000 5
ML.TRANSLATE 6,000 2,160,000 5
ML.UNDERSTAND_TEXT 600 21,600 5

Vertex AI LLM と Cloud AI サービス API の割り当ての詳細については、次のドキュメントをご覧ください。

ジョブあたりの行数の割り当ては、システムが 6 時間以内に処理できる理論上の最大行数を表します。処理される行の実際の数は、入力サイズやネットワーク状態など、他の多くの要因によって異なります。たとえば、ML.TRANSCRIBE は長い音声よりも短い音声をより多く処理できます。

BigQuery ML 関数の割り当ての増加をリクエストするには、まず、関連付けられた Vertex AI LLM または Cloud AI サービスの割り当てを調整してから、bqml-feedback@google.com にメールを送信して、調整された LLM または Cloud AI サービス割り当てに関する情報を記載します。これらのサービスの割り当ての増加をリクエストする方法については、割り当ての増加をリクエストするをご覧ください。

割り当ての定義

次のリストは、Vertex AI と Cloud AI のサービス関数に適用される割り当てをまとめたものです。

  • Vertex AI 基盤モデルを呼び出す関数は、1 分あたりのクエリ数（QPM）である Vertex AI 割り当てを 1 つ使用します。このコンテキストでは、クエリは関数から Vertex AI モデルの API へのリクエスト呼び出しです。QPM の割り当ては、ベースモデルと、そのモデルのすべてのバージョン、識別子、チューニング済みバージョンに適用されます。Vertex AI 基盤モデルの割り当ての詳細については、リージョンとモデルごとの割り当てをご覧ください。
  • Cloud AI サービスを呼び出す関数は、ターゲット サービスのリクエスト割り当てを使用します。詳細については、該当する Cloud AI サービスの割り当てリファレンスをご覧ください。

  • BigQuery ML では、次の 3 つの割り当てが使用されます。

    • 1 分あたりのリクエスト数。この割り当ては、関数が Vertex AI モデルまたは Cloud AI サービスの API に対して行うことができるリクエスト呼び出しの 1 分あたりの上限です。この上限はプロジェクトごとに適用されます。

      Vertex AI 基盤モデルを呼び出す関数の場合、1 分あたりのリクエスト呼び出し数は、Vertex AI モデルのエンドポイント、バージョン、リージョンによって異なります。この割り当ては、概念的には Vertex AI で使用される QPM 割り当てと同じですが、対応するモデルの QPM 割り当てよりも小さい値になる場合があります。

    • 1 ジョブあたりの行数。この割り当ては、クエリジョブごとに許可される行数の上限です。

    • 同時に実行されているジョブの数。この割り当ては、特定の関数に対して同時に実行できる SQL クエリの数に対するプロジェクトごとの上限です。

次の例は、一般的な状況で割り当ての上限を解釈する方法を示しています。

  • Vertex AI の割り当ては 1,000 QPM であるため、100,000 行のクエリには約 100 分かかります。ジョブの実行時間が長くなるのはなぜですか？

    同じ入力データでも、ジョブの実行時間は異なる場合があります。Vertex AI では、割り当ての枯渇を回避するために、リモート プロシージャ コール（RPC）の優先度が異なります。割り当てが十分でない場合、優先度の低い RPC は待機し、処理に時間がかかりすぎると失敗する可能性があります。

  • ジョブあたりの行割り当てはどのように解釈すればよいですか？

    BigQuery では、クエリの実行時間は最大 6 時間です。サポートされる最大行数は、このタイムラインと Vertex AI QPM 割り当ての関数です。これにより、BigQuery は 6 時間以内にクエリ処理を完了できます。通常、クエリで割り当て全体を使用できないため、この値は QPM 割り当てに 360 を掛けた値よりも小さくなります。

  • ジョブ割り当てあたりの行数よりも多くの行（10,000,000 行など）を含むテーブルでバッチ推論ジョブを実行するとどうなりますか？

    BigQuery は、ジョブあたりの行数割り当てで指定された行数のみ処理します。テーブルの 10,000,000 行すべてではなく、その行数に対する API 呼び出しが成功した場合のみ課金されます。残りの行については、BigQuery は A retryable error occurred: the maximum size quota per query has reached エラーでリクエストに応答します。このエラーは、結果の status 列で返されます。この SQL スクリプトまたはこの Dataform パッケージを使用して、すべての行が正常に処理されるまで推論呼び出しを反復できます。

  • ジョブ割り当てあたりの行数よりも多くの行を処理する必要があります。行を複数のクエリに分割して同時に実行すると、問題は解決しますか？

    いいえ。これらのクエリは、1 分あたりの BigQuery ML リクエストと Vertex AI QPM 割り当てを消費します。ジョブ割り当てあたりの行数と、同時に実行されるジョブの割り当てに収まる複数のクエリがある場合、累積処理によって 1 分あたりのリクエストの割り当てが使い果たされます。

BI Engine

BigQuery BI Engine には次の上限が適用されます。

上限 デフォルト 注
ロケーションごとのプロジェクトあたりの最大予約サイズ（SQL インターフェース） 250 GiB BigQuery で BI Engine を使用している場合に適用されます。ネイティブ インテグレーションのない Looker Studio を除くすべてのケースに適用されます。

プロジェクトの最大予約容量の増加をリクエストできます。予約の増加はほとんどのリージョンで利用でき、処理に 3 日間～1 週間かかることがあります。
ロケーションごとのプロジェクトあたりの最大予約サイズ（Looker Studio） 100 GB ネイティブ インテグレーションなしで Looker Studio で BI Engine を使用している場合に適用されます。この上限は、クエリの対象となるテーブルのサイズには影響しません。これは、BI Engine は、テーブル全体ではなくクエリで使用される列のみをメモリ内に読み込むためです。
テーブルあたりのデータモデルの最大サイズ（Looker Studio） 10 GB ネイティブ インテグレーションなしで Looker Studio で BI Engine を使用している場合に適用されます。1 つのロケーションのプロジェクトごとに 100 GB の予約がある場合、BI Engine はテーブルごとの予約を 10 GB に制限します。残りの利用可能な予約は、プロジェクトの他のテーブルに使用されます。
テーブルあたりの最大パーティション数（Looker Studio） 500 個のパーティション ネイティブ インテグレーションなしで Looker Studio で BI Engine を使用している場合に適用されます。Looker Studio 用の BI Engine は、テーブルあたり最大 500 個のパーティションをサポートします。
クエリあたりの最大行数（Looker Studio） 1 億 5,000 万 ネイティブ インテグレーションなしで Looker Studio で BI Engine を使用している場合に適用されます。Looker Studio 用の BI Engine は、クエリの複雑さに応じて、最大 1 億 5,000 万行のクエリされたデータをサポートします。

Analytics Hub

Analytics Hub には以下の各上限が適用されます。

上限 デフォルト 注
プロジェクトあたりのデータ交換の最大数 500 回のデータ交換 1 つのプロジェクトに最大 500 回のデータ交換を作成できます。
データ交換あたりの最大リスティング数 1,000 件のリスティング 1 回のデータ交換で最大 1,000 件のリスティングを作成できます。
共有データセットあたりのリンクされたデータセットの最大数 1,000 個のリンクされたデータセット すべての Analytics Hub サブスクライバーの合計には、共有データセットあたり最大 1,000 個のリンクされたデータセットを含めることができます。

API の割り当てと上限

BigQuery API リクエストには、以下の割り当てと上限が適用されます。

BigQuery API

BigQuery API（コア）リクエストには、次の割り当てが適用されます。

割り当て デフォルト 注
1 日あたりのリクエスト数 無制限 プロジェクトで、1 日に実行できる BigQuery API リクエストの数に制限はありません。
Google Cloud コンソールで割り当てを表示する
1 分あたりの最大 tabledata.list バイト数 マルチリージョンで 7.5 GB。他のすべてのリージョンで 3.7 GB プロジェクトは、us と eu のマルチリージョンで tabledata.list を介して 1 分あたり最大 7.5 GB のテーブル行データを返し、他のすべてのリージョンで 1 分あたり最大 3.7 GB のテーブル行データを返すことができます。この割り当ては、読み取られるテーブルを含むプロジェクトに適用されます。その他の API（jobs.getQueryResults、jobs.query や jobs.insert からの結果の取得など）でも、この割り当てが消費されることがあります。
Google Cloud コンソールで割り当てを表示する

BigQuery Storage Read API は、tabledata.list よりもはるかに高いスループットを維持できます。この割り当てで許可されているスループットを超えるスループットが必要である場合は、BigQuery Storage Read API の使用をおすすめします。

BigQuery API（コア）リクエストには、次の上限が適用されます。

上限 デフォルト 注
メソッド、ユーザーごとの 1 秒あたりの API リクエストの最大数 100 リクエスト ユーザーは 1 つの API メソッドに対して 1 秒あたり最大 100 個の API リクエストを送信できます。ユーザーが 1 秒あたり 100 個を超えるリクエストをメソッドに送信すると、スロットリングが発生する可能性があります。この上限はストリーミング挿入に適用されません。
ユーザーごとの同時 API リクエストの最大数 300 リクエスト ユーザーが 300 個を超えるリクエストを同時に発行すると、スロットリングが発生する可能性があります。この上限はストリーミング挿入に適用されません。
リクエスト ヘッダーの最大サイズ 16 KiB BigQuery API リクエストの最大サイズは 16 KiB です。これには、リクエスト URL とすべてのヘッダーが含まれます。この上限は、POST リクエストなどのリクエスト本文には適用されません。
1 秒あたりの jobs.get リクエストの最大数 1,000 件のリクエスト プロジェクトで 1 秒あたり最大 1,000 個の jobs.get リクエストを送信できます。
jobs.query レスポンスの最大サイズ 20 MB デフォルトでは、結果のページあたりに jobs.query によって返されるデータ行の最大行数は設定されていません。ただし、レスポンスの最大サイズは 20 MB に制限されています。返される行数は maxResults パラメータを使用して変更できます。
jobs.getQueryResults 行の最大サイズ 20 MB 行のサイズは行データの内部表現に基づくため、その最大サイズは概算値になります。この上限はコード変換時に適用されます。
1 秒あたりの projects.list リクエストの最大数 2 件のリクエスト プロジェクトで 1 秒あたり最大 2 件の projects.list リクエストを送信できます。
1 秒あたりの tabledata.list リクエストの最大数 1,000 件のリクエスト プロジェクトで 1 秒あたり最大 1,000 件の tabledata.list リクエストを送信できます。
tabledata.list レスポンスあたりの最大行数 100,000 行 tabledata.list 呼び出しで、最大 100,000 個のテーブル行を返すことができます。詳細については、API を使用して結果をページ分割するをご覧ください。
tabledata.list 行の最大サイズ 100 MB 行のサイズは行データの内部表現に基づくため、その最大サイズは概算値になります。この上限はコード変換時に適用されます。
1 秒あたりの tables.insert リクエストの最大数 10 件のリクエスト プロジェクトで 1 秒あたり最大 10 件の tables.insert リクエストを送信できます。tables.insert メソッドは、空のテーブルをデータセットに新規作成します。この上限には、CREATE TABLE などのテーブルを作成する SQL ステートメントと、宛先テーブルに結果を書き込むクエリが含まれます。

BigQuery Connection API

BigQuery Connection API リクエストには、次の割り当てが適用されます。

割り当て デフォルト 注
1 分あたりの読み取りリクエスト数 1 分あたり 1,000 件のリクエスト プロジェクトで、接続データを読み取る BigQuery Connection API メソッドに 1 分あたり最大 1,000 件のリクエストを送信できます。
Google Cloud コンソールで割り当てを表示する
1 分あたりの書き込みリクエスト数 1 分あたり 100 リクエスト プロジェクトで、接続を作成または更新する BigQuery Connection API メソッドに 1 分あたり最大 100 件のリクエストを送信できます。
Google Cloud コンソールで割り当てを表示する
1 分あたりに作成される BigQuery Omni 接続数 1 分あたり 10 個の接続を作成 プロジェクトで、AWS と Azure の両方で 1 分あたり最大 10 個の BigQuery Omni 接続を作成できます。
BigQuery Omni 接続の使用回数 1 分あたり 100 回の接続を使用 プロジェクトで BigQuery Omni 接続を 1 分あたり最大 100 回使用できます。これは、テーブルに対するクエリ実行など、接続を使用して AWS アカウントにアクセスするオペレーションに適用されます。

BigQuery Migration API

BigQuery Migration API には、次の上限が適用されます。

上限 デフォルト 注
バッチ SQL 変換の個別のファイルサイズ 10 MB それぞれのソースファイルとメタデータ ファイルに許容される最大サイズは 10 MB です。この上限は、dwh-migration-dumper コマンドライン抽出ツールによって生成されたメタデータ zip ファイルには適用されません。
バッチ SQL 変換に使用するソースファイルの合計サイズ 1 GB Cloud Storage にアップロードされたすべての入力ファイルに許容される合計サイズは最大 1 GB です。これには、すべてのソースファイルと、追加することを選択したすべてのメタデータ ファイルが含まれます。
インタラクティブ SQL 変換の入力文字列サイズ 1 MB インタラクティブ SQL 変換の対象として入力する文字列は 1 MB 以下にする必要があります。Translation API を使用してインタラクティブ変換を実行する場合、この上限はすべての文字列入力の合計サイズに適用されます。
インタラクティブ SQL 変換の最大構成ファイルサイズ 50 MB Cloud Storage の各メタデータ ファイル（圧縮ファイル）と YAML 構成ファイルは 50 MB 以下にする必要があります。ファイルサイズが 50 MB を超えると、インタラクティブ トランスレータは変換中にその構成ファイルをスキップし、エラー メッセージを生成します。メタデータ ファイルサイズを減らす方法の 1 つは、メタデータを生成するときに —database フラグまたは –schema フラグを使用してデータベースをフィルタリングすることです。

BigQuery Migration API には、次の割り当てが適用されます。ほとんどの場合、次のデフォルト値が適用されます。プロジェクトのデフォルトは、これとは異なる場合があります。

割り当て デフォルト 注

1 分あたりの EDWMigration Service List リクエスト数

1 ユーザー、1 分あたりの EDWMigration Service List リクエスト数

12,000 件のリクエスト

2,500 件のリクエスト

プロジェクトで、1 分あたり最大 12,000 件の Migration API List リクエストを送信できます。

各ユーザーは 1 分あたり最大 2,500 件の Migration API List リクエストを送信できます。

Google Cloud コンソールで割り当てを表示する

1 分あたりの EDWMigration Service GET リクエスト数

1 ユーザー、1 分あたりの EDWMigration Service GET リクエスト数

25,000 件のリクエスト

2,500 件のリクエスト

プロジェクトで、1 分あたり最大 25,000 件の Migration API GET リクエストを送信できます。

各ユーザーは 1 分あたり最大 2,500 件の Migration API GET リクエストを送信できます。

Google Cloud コンソールで割り当てを表示する

1 分あたりの EDWMigration Service のその他のリクエスト数

1 ユーザー、1 分あたりの EDWMigration Service のその他のリクエスト数

25 件のリクエスト

5 件のリクエスト

プロジェクトで、1 分あたり最大 25 件の他の Migration API リクエストを送信できます。

各ユーザーは 1 分間に最大 5 件の他の Migration API リクエストを送信できます。

Google Cloud コンソールで割り当てを表示する

1 分あたりのインタラクティブ SQL 変換リクエスト数

1 ユーザー、1 分あたりのインタラクティブ SQL 変換リクエスト数

200 件のリクエスト

50 件のリクエスト

プロジェクトで、1 分あたり最大 200 件の SQL 変換サービス リクエストを送信できます。

各ユーザーは 1 分間に最大 50 件の他の SQL 変換サービス リクエストを送信できます。

Google Cloud コンソールで割り当てを表示する

BigQuery Reservation API

BigQuery Reservation API リクエストには、次の割り当てが適用されます。

割り当て デフォルト 注
1 リージョン 1 分あたりのリクエスト数 100 リクエスト プロジェクトで、リージョンごとに 1 分あたり合計 100 回まで BigQuery Reservation API メソッドを呼び出すことができます。
Google Cloud コンソールで割り当てを表示する
1 リージョン、1 分あたりの SearchAllAssignments 呼び出しの数 100 リクエスト プロジェクトで、リージョンごとに 1 分あたり最大 100 回まで SearchAllAssignments メソッドを呼び出すことができます。
Google Cloud コンソールで割り当てを表示する
1 リージョン、1 ユーザー、1 分あたりの SearchAllAssignments リクエスト数 10 件のリクエスト 各ユーザーは、リージョンごとに 1 分あたり SearchAllAssignments メソッドを 10 回まで呼び出すことができます。
Google Cloud コンソールで割り当てを表示する
（Google Cloud コンソールの検索結果で、ユーザーあたりを検索します。）

BigQuery Data Policy API

Data Policy API（プレビュー）には、次の上限が適用されます。

上限 デフォルト 注
dataPolicies.list 呼び出しの最大数。 1 プロジェクト、1 分あたり 400 回のリクエスト

組織あたり 1 分あたり 600 回のリクエスト
dataPolicies.testIamPermissions 呼び出しの最大数。 1 プロジェクト、1 分あたり 400 回のリクエスト

組織あたり 1 分あたり 600 回のリクエスト
読み取りリクエストの最大数。 1 プロジェクトあたり毎分 1,200 回のリクエスト

組織あたり毎分 1,800 回のリクエスト		 これには、dataPolicies.get と dataPolicies.getIamPolicy の呼び出しが含まれます。
書き込みリクエストの最大数。 1 プロジェクト、1 分あたり 600 回のリクエスト

組織あたり 1 分あたり 900 回のリクエスト

これには、次の呼び出しが含まれます。

IAM API

BigQuery で Identity and Access Management 機能を使用して IAM ポリシーの取得と設定を行い、IAM の権限をテストする場合、次の割り当てが適用されます。データ制御言語（DCL）ステートメントは、SetIAMPolicy の割り当てにカウントされます。

割り当て デフォルト 注
1 ユーザー、1 分あたりの IamPolicy リクエスト 1 ユーザー、1 分あたり 1,500 件のリクエスト 各ユーザーは、プロジェクトごとに 1 分あたり最大 1,500 件のリクエストを送信できます。
Google Cloud コンソールで割り当てを表示する
1 プロジェクト、1 分あたりの IamPolicy リクエスト 1 プロジェクト、1 分あたり 3,000 件のリクエスト プロジェクトで 1 分あたり最大 3,000 件のリクエストを送信できます。
Google Cloud コンソールで割り当てを表示する
1 プロジェクト、1 分あたりの単一リージョンでの SetIAMPolicy リクエスト 1 プロジェクト、1 分あたり 1,000 件のリクエスト 単一リージョンのプロジェクトで、1 分あたり最大 1,000 件のリクエストを送信できます。
Google Cloud コンソールで割り当てを表示する
1 プロジェクト、1 分あたりのマルチリージョンでの SetIAMPolicy リクエスト 1 プロジェクト、1 分あたり 2,000 件のリクエスト マルチリージョンのプロジェクトで、1 分あたり最大 2,000 件のリクエストを送信できます。
Google Cloud コンソールで割り当てを表示する
1 プロジェクト、1 分あたりの Omni リージョンでの SetIAMPolicy リクエスト 1 プロジェクト、1 分あたり 200 件のリクエスト Omni リージョンのプロジェクトで、1 分あたり最大 200 件のリクエストを送信できます。
Google Cloud コンソールで割り当てを表示する

Storage Read API

BigQuery Storage Read API リクエストには、次の割り当てが適用されます。

割り当て デフォルト 注
1 ユーザー、1 分あたりの読み取りデータプレーン リクエスト数 25,000 件のリクエスト 各ユーザーは、プロジェクトごとに 1 分あたり最大 25,000 回の ReadRows 呼び出しを行うことができます。
Google Cloud コンソールで割り当てを表示する
ユーザーごとの 1 分あたりの読み取りコントロール プレーン リクエスト数 5,000 リクエスト 各ユーザーは、プロジェクトごとに 1 分あたり最大 5,000 個の Storage Read API メタデータ オペレーションを呼び出すことができます。メタデータ呼び出しには、CreateReadSession メソッドと SplitReadStream メソッドが含まれます。
Google Cloud コンソールで割り当てを表示する

BigQuery Storage Read API リクエストには、次の上限が適用されます。

上限 デフォルト 注
行とフィルタの最大長 1 MB Storage Read API の CreateReadSession 呼び出しを使用する場合、各行またはフィルタの最大長は 1 MB に制限されます。
シリアル化されたデータの最大サイズ 128 MB Storage Read API の ReadRows 呼び出しを使用する場合、個々の ReadRowsResponse メッセージ内のデータのシリアル化された表現は 128 MB 以下にする必要があります。
最大同時接続数 マルチ リージョンでは 2,000、リージョンでは 400 us と eu のマルチリージョンでは、プロジェクトごとに最大 2,000 個の ReadRows 接続を同時に開くことができます。その他のリージョンでは最大 400 個の ReadRows 接続を同時に開くことができます。場合によっては、この上限よりも少ない同時接続数に制限されます。
ストリームあたりの最大メモリ使用量 1.5 GB 上限は行データの内部表現に基づくため、ストリームあたりの最大メモリは概算値になります。1 行に 1.5 GB を超えるメモリを使用するストリームは失敗する可能性があります。詳細については、リソース超過に関する問題のトラブルシューティングをご覧ください。

Storage Write API

Storage Write API リクエストには、次の割り当てが適用されます。次の割り当ては、フォルダレベルで適用できます。これらの割り当ては、すべての子プロジェクトで集計され、共有されます。この構成を有効にするには、Cloud カスタマーケアにお問い合わせください。

割り当て上限の引き上げをリクエストする予定の場合は、迅速に処理されるようリクエストに割り当てエラー メッセージを含めてください。

割り当て デフォルト 注
同時接続数 1,000（リージョン）、10,000（マルチリージョン）

同時接続数の割り当ては、BigQuery データセット リソースを含むプロジェクトではなく、Storage Write API リクエストを開始するクライアント プロジェクトに基づいて決まります。開始中のプロジェクトとは、API キーまたはサービス アカウントに関連付けられているプロジェクトのことです。

ご使用のプロジェクトでは、1 つのリージョンで 1,000 の同時接続を処理できます。US と EU のマルチリージョンでは 10,000 の同時接続を使用できます。

Java または Go でデフォルト ストリームを使用する場合、必要となる全体的な接続数を減らすため、Storage Write API 多重化を使用して、接続を共有する複数の宛先テーブルに書き込むことをおすすめします。at-least-once（少なくとも 1 回）セマンティクスで Beam コネクタを使用している場合は、UseStorageApiConnectionPool を TRUE に設定して、多重化を有効にできます。

Google Cloud コンソールで割り当てを表示する

プロジェクトの割り当てと上限の指標は、Cloud Monitoring で確認できます。リージョンに基づいて同時接続上限の名前を選択します。us、eu、その他のリージョンのオプションは、それぞれ ConcurrentWriteConnectionsPerProject、ConcurrentWriteConnectionsPerProjectEU、ConcurrentWriteConnectionsPerProjectRegion です。

割り当ての使用量と上限をモニタリングするためのアラートを設定することを強くおすすめします。また、トラフィック パターンが急増したり、定期的に有機的に成長したりする場合は、予期しない需要に対応するために割り当てを 25～50% オーバープロビジョニングすることをおすすめします。
スループット マルチリージョンでは 3 GB/秒のスループット。リージョンで 300 MB/秒のスループット us と eu のマルチリージョンでは最大 3 GBps をストリーミングでき、プロジェクトごとに他のリージョンでは最大 300 MBps をストリーミングできます。
Google Cloud コンソールで割り当てを表示する

プロジェクトの割り当てと上限の指標は、Cloud Monitoring で確認できます。リージョンに基づいてスループット上限の名前を選択します。us、eu、その他のリージョンのオプションは、それぞれ AppendBytesThroughputPerProject、AppendBytesThroughputPerProjectEU、AppendBytesThroughputPerProjectRegion です。書き込みスループットの割り当ては、クライアント プロジェクトではなく、ターゲット データセットが存在するプロジェクトに基づいて計測されます。

割り当ての使用量と上限をモニタリングするためのアラートを設定することを強くおすすめします。また、トラフィック パターンが急増したり、定期的に有機的に成長したりする場合は、予期しない需要に対応するために割り当てを 25～50% オーバープロビジョニングすることをおすすめします。
CreateWriteStream リクエスト 1 リージョン、1 プロジェクト、1 時間あたり 10,000 ストリーム CreateWriteStream は、リージョン、プロジェクトごとに 1 時間あたり最大 10,000 回呼び出すことができます。セマンティクスが 1 回だけの場合は、デフォルト ストリームの使用を検討してください。この割り当ては 1 時間単位ですが、Google Cloud コンソールに表示される指標は 1 分単位です。
保留中のストリーム バイト数 マルチリージョンでは 10 TB、リージョンでは 1 TB トリガーする commit ごとに、us と eu のマルチリージョンでは最大 10 TB を、他のリージョンでは最大 1 TB を commit できます。この割り当てに関するレポートはありません。

Storage Write API リクエストには、次の上限が適用されます。

上限 デフォルト 注
まとめて commit する テーブルあたり 10,000 ストリーム 1 回の BatchCommitWriteStream 呼び出しで最大 10,000 のストリームを commit できます。
AppendRows リクエスト サイズ 10 MB リクエストの最大サイズは 10 MB です。

ストリーミング挿入

以前のストリーミング API を使用して BigQuery にデータをストリーミングする場合は、次の割り当てと上限が適用されます。これらの上限に収める方法については、割り当てエラーのトラブルシューティングをご覧ください。これらの割り当てを超えると、quotaExceeded エラーが発生します。

上限 デフォルト 注
us と eu のマルチリージョンにおけるプロジェクトごとの 1 秒あたりの最大バイト数 毎秒 1 GB

プロジェクトのストリーミングは 1 秒あたり最大 1 GB です。この割り当ては、特定のマルチリージョン内で累積的に処理されます。つまり、マルチリージョン内にある特定のプロジェクトのすべてのテーブルにストリーミングされる 1 秒あたりのバイト数の合計は 1 GB に制限されます。

この上限を超えると、quotaExceeded エラーが発生します。

必要に応じて、Cloud カスタマーケアに連絡して、割り当ての増加をリクエストできます。増加はできるだけ早く（必要になる少なくとも 2 週間前）にリクエストしてください。特に割り当てが大幅に増加した場合は、割り当ての増加に時間がかかります。
他のすべてのロケーションでプロジェクトごとの 1 秒あたりの最大バイト数 1 秒あたり 300 MB

プロジェクトでは、us と eu のマルチリージョン以外のすべてのロケーションで、1 秒あたり最大 300 MB をストリーミングできます。この割り当ては、特定のマルチリージョン内で累積的に処理されます。つまり、リージョン内にある特定のプロジェクトのすべてのテーブルにストリーミングされる 1 秒あたりのバイト数の合計は 300 MB に制限されます。

この上限を超えると、quotaExceeded エラーが発生します。

必要に応じて、Cloud カスタマーケアに連絡して、割り当ての増加をリクエストできます。増加はできるだけ早く（必要になる少なくとも 2 週間前）にリクエストしてください。特に割り当てが大幅に増加した場合は、割り当ての増加に時間がかかります。
最大行数 10 MB この値を超えると invalid エラーが発生します。
HTTP リクエストのサイズ上限 10 MB

この値を超えると invalid エラーが発生します。

内部的に、リクエストは HTTP JSON から内部データ構造に変換されます。変換されたデータ構造には、独自のサイズ上限が適用されます。変換後の内部データ構造のサイズを予測することは困難ですが、HTTP リクエストを 10 MB 以下に保つと、内部上限に達する可能性は低くなります。
リクエストあたりの最大行数 50,000 行 最大行数は 500 行をおすすめします。一括処理することでパフォーマンスとスループットをある程度向上させることはできますが、リクエストごとのレイテンシは高くなります。リクエストごとの行数が少なく、各リクエストにオーバーヘッドがあると取り込みの効率が下がります。また、リクエストごとの行数が多すぎるとスループットが下がります。代表的なデータ（スキーマとデータサイズ）を試して、データに最適なバッチサイズを決定します。
insertId フィールドの長さ 128 文字 この値を超えると invalid エラーが発生します。

追加のストリーミング割り当てについては、割り当ての増加をリクエストするをご覧ください。

帯域幅

レプリケーション帯域幅には、次の割り当てが適用されます。

割り当て デフォルト 注
プライマリ レプリカからセカンダリ レプリカへのクロスリージョン下り（外向き）データがある各リージョンの最初のバックフィル レプリケーションの最大帯域幅。 ほとんどのプロジェクトでは、リージョンあたり 10 物理 GiBps の割り当て
プライマリ レプリカからセカンダリ レプリカへのクロスリージョン下り（外向き）データがある各リージョンの継続的なレプリケーションの最大帯域幅。 ほとんどのプロジェクトでは、リージョンあたり 5 物理 GiBps の割り当て
プライマリ レプリカからセカンダリ レプリカへのクロスリージョン下り（外向き）データがある各リージョンのターボ レプリケーションの最大帯域幅。 ほとんどのプロジェクトでは、リージョンあたり 5 物理 GiBps のデフォルトの割り当て ターボ レプリケーション帯域幅の割り当ては、最初のバックフィル オペレーションには適用されません。

プロジェクトのレプリケーション帯域幅が特定の割り当てを超えると、影響を受けるプロジェクトからのレプリケーションが停止し、超過した割り当ての詳細を含む rateLimitExceeded エラーが発生することがあります。