割り当てと上限

このドキュメントでは、BigQuery の割り当てと上限について説明します。

割り当ては、Google Cloud プロジェクトで使用できる特定の共有 Google Cloud リソース(ハードウェア、ソフトウェア、ネットワーク コンポーネントなど)の量を制限します。

割り当てはシステムの一部で、次の機能があります。

  • Google Cloud のプロダクトとサービスの使用量や消費量をモニタリングする。
  • 公平性の確保や使用量急増の抑制などのため、これらのリソースの消費量を制限する。
  • 規定の制限を自動的に適用する構成を維持する。
  • 割り当ての変更を実施またはリクエストする手段を提供する。

割り当てを超過すると、ほとんどの場合、システムは関連する Google リソースへのアクセスをすぐにブロックするため、ユーザーが試行しているタスクは失敗します。ほとんどの場合、割り当ては各 Google Cloud プロジェクトに適用され、その Google Cloud プロジェクトを使用するすべてのアプリケーションと IP アドレスで共有されます。

BigQuery リソースには制限もあります。これらの上限は、割り当てシステムとは無関係です。上限は、特に明記されていない限り、変更できません。

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

割り当ての補充

毎日の割り当ては、レート制限動作をガイドするという意図を反映して、一日中一定の間隔で補充されます。割り当てを使い切った場合の分断が長時間にならないようにするためにも、断続的な更新が行われます。通常、割り当ては 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 件のバッチクエリをキューに入れることができます。この上限を超えるバッチクエリを追加しようとすると、割り当てエラーが返されます。
Cloud 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 時間以上になることがあります。
1 つのクエリで参照可能なリソースの最大数 1,000 個のリソース 1 つのクエリで、一意のテーブル、一意のビュー、一意のユーザー定義関数(UDF)、完全展開後の一意のテーブル関数を合計 1,000 個まで参照できます。この上限には次のものが含まれます。
  • クエリで直接参照されるテーブル、ビュー、UDF、テーブル関数。
  • クエリで参照される他のビュー、UDF、テーブル関数によって参照されるテーブル、ビュー、UDF、テーブル関数。
  • クエリで使用される他のワイルドカード テーブル、またはその他の参照されるビュー/ UDF / テーブル関数から展開されたテーブル。
未解決レガシー 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 スロット オンデマンド料金では、プロジェクトで最大 2,000 個の同時実行スロットを設定できます。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 TB 共有スロットプールを使用して、プロジェクトから 1 日あたり最大 50 TB(テビバイト)のデータを無料でエクスポートできます。エクスポートしたバイト数の通知を提供する Cloud Monitoring アラート ポリシーを設定できます。 1 日あたり 50 TB(テビバイト)を超えるデータをエクスポートするには、次のいずれかを行います。
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 ジョブ プロジェクトで 1 日あたり最大 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: 行の最大サイズ 100 MB JSON 行のサイズは最大 100 MB です。
JSON: 最大ファイルサイズ - 圧縮 4 GB 圧縮 JSON ファイルのサイズの上限は 4 GB です。
JSON: 最大ファイルサイズ - 非圧縮 5 TB 非圧縮 JSON ファイルのサイズの上限は 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 コンソール、コマンドライン ツール、または copy-type の 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 件の予約 特定のロケーション / リージョンにおける、組織内の管理プロジェクトごとの標準エディションの予約の最大数。

データセット

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 日あたりのテーブル変更の数にカウントされません。

テーブルあたりのテーブル メタデータ更新オペレーションの最大レート 10 秒あたり 5 個のオペレーション プロジェクトで、テーブルごとに 10 秒あたり最大 5 個のテーブル メタデータ更新オペレーションを実行できます。この上限は、以下によって実行されるすべてのテーブル メタデータ更新オペレーションに適用されます。
  • Google Cloud コンソール
  • bq コマンドライン ツール
  • BigQuery クライアント ライブラリ
  • 次の API メソッド:
  • テーブルに対する DDL ステートメント
この上限には、宛先テーブルを追加または上書きする、または、DML DELETEINSERTMERGETRUNCATE 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 では、ジョブで消費される上限を決定する際に、ジョブの対象であるパーティションの数を使用します。ストリーミング挿入はこの上限に影響しません。

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

上限 デフォルト
パーティション分割テーブルあたりのパーティション数 4,000 個のパーティション 各パーティション分割テーブルには、最大 4,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 日あたりのパーティション変更の数にカウントされません。

パーティション分割テーブルあたりのテーブル メタデータ更新オペレーションの最大レート 10 秒あたり 50 件の変更 プロジェクトでは、10 秒ごとに最大 50 件の変更をパーティション分割テーブルごとに実行できます。この上限は、以下によって実行されるすべてのパーティション分割テーブル メタデータ更新オペレーションに適用されます。
  • Google Cloud コンソール
  • bq コマンドライン ツール
  • BigQuery クライアント ライブラリ
  • 次の API メソッド:
  • テーブルに対する DDL ステートメント
この上限には、宛先テーブルを追加または上書きする、または、DML DELETEINSERTMERGETRUNCATE 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 レベルまでのネストビューをサポートします。ネストレベルが 16 を超えると、INVALID_INPUT エラーが返されます。
ビューの定義に使用される GoogleSQL クエリの最大長 256,000 文字 ビューを定義する GoogleSQL クエリのテキストは、最大 256,000 文字です。
データセットあたりの承認済みビューの最大数 データセットをご覧ください。

マテリアライズド ビュー

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

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

インデックス

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

上限 デフォルト
1 プロジェクト、1 リージョン、1 日あたりの CREATE INDEX DDL ステートメントの数 500 件のオペレーション プロジェクトでは、1 つのリージョン内で 1 日あたり最大 500 件の CREATE INDEX DDL オペレーションを発行できます。
テーブルごとの 1 日あたりの INDEX DDL ステートメントの数 20 件のオペレーション プロジェクトでは、1 日あたりテーブルごとに最大 20 件の CREATE INDEX または DROP INDEX DDL オペレーションを発行できます。
予約で実行されないインデックス作成が許可される組織ごとのテーブルデータの最大サイズ マルチリージョンで 100 TB。他のすべてのリージョンで 20 TB 組織のインデックスを持つテーブルの全体的なサイズが、リージョンの上限(USEU のマルチリージョンで 100 TB。その他すべてのリージョンで 20 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 Functions 第 1 世代) 10 MB Cloud Functions 第 1 世代の HTTP レスポンス本文の上限は 10 MB です。この値を超えると、クエリが失敗します。
HTTP レスポンス サイズの上限(Cloud Functions 第 2 世代または Cloud Run) 15 MB Cloud Functions 第 2 世代または Cloud Run からの HTTP レスポンス本文の上限は 15 MB です。この値を超えると、クエリが失敗します。
最大 HTTP 呼び出し時間上限(Cloud Functions 第 1 世代) 9 分 Cloud Functions 第 1 世代には、個々の HTTP 呼び出しに独自の制限時間を設定できますが、最大制限時間は 9 分です。 Cloud Functions 第 1 世代に設定された制限時間を超えると、上限回数の再試行後に HTTP 呼び出しの失敗とクエリの失敗が発生することがあります。
HTTP 呼び出しの制限時間(Cloud Functions 第 2 世代または Cloud Run) 20 分 Cloud Functions 第 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 のノートブック(プレビュー)をご覧ください。次の上限も適用されます。

上限 デフォルト
ノートブックの最大サイズ 10 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 ステートメントには、注意すべき次の制限事項があります。
テーブルごとの同時変更 DML ステートメント 2 個のステートメント BigQuery では、テーブルごとに最大 2 個の同時変更 DML ステートメント(UPDATEDELETEMERGE)が実行されます。テーブルに対する追加の変更 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 サービスを利用してトレーニングされます。

Cloud AI サービスの関数

Cloud AI サービスの関数には、次の上限が適用されます。

ML.ANNOTATE_IMAGE ML.TRANSLATE ML.UNDERSTAND_TEXT ML.GENERATE_TEXT ML.GENERATE_TEXT_EMBEDDING
1 分あたりのリクエスト数 900 3,000 300 60 600
1 ジョブあたりの行数 307,800 1,026,000 102,600 30,000 500,000
同時に実行されているジョブの数 5 5 5 5 1

これらの API のレート割り当ての増加をリクエストする方法については、Cloud Translation API の割り当てと上限Vision API の割り当てと上限Natural Language API の割り当てと上限をご覧ください。

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

ML.GENERATE_TEXT の場合、1 分あたりのリクエストの割り当ては、リクエストの割り当てに記載されている base_model:text-bison の割り当てによって異なります。

BI Engine

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

上限 デフォルト
ロケーションごとのプロジェクトあたりの最大予約サイズ(SQL インターフェース 250 GB Looker Studio 以外のビジネス インテリジェンス(BI)ツールで BI Engine を使用する場合に適用されます。

プロジェクトの最大予約容量の増加をリクエストできます。予約の増加はほとんどのリージョンで利用でき、処理に 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 は、テーブルあたり最大 500 個のパーティションをサポートします。
クエリあたりの最大行数(Looker Studio 1 億 5,000 万 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 プロジェクトは、useu のマルチリージョンで tabledata.list を介して 1 分あたり最大 7.5 GB のテーブル行データを返し、他のすべてのリージョンで 1 分あたり最大 3.7 GB のテーブル行データを返すことができます。この割り当ては、読み取られるテーブルを含むプロジェクトに適用されます。その他の API(jobs.getQueryResultsjobs.queryjobs.insert からの結果の取得など)でも、この割り当てが消費されることがあります。
Google Cloud コンソールで割り当てを表示する

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 パラメータを使用して変更できます。
1 秒あたりの projects.list リクエストの最大数 2 件のリクエスト プロジェクトで 1 秒あたり最大 2 件の projects.list リクエストを送信できます。
1 秒あたりの tabledata.list リクエストの最大数 1,000 件のリクエスト プロジェクトで 1 秒あたり最大 1,000 件の tabledata.list リクエストを送信できます。
1 秒間に tabledata.list リクエストから返される最大行数 150,000 行 プロジェクトで、tabledata.list リクエストを使用して 1 秒あたり最大 150,000 行を返すことができます。この上限は、読み取られるテーブルを含むプロジェクトに適用されます。
tabledata.list レスポンスあたりの最大行数 100,000 行 tabledata.list 呼び出しで、最大 100,000 個のテーブル行を返すことができます。詳細については、API を使用した結果のページ分割をご覧ください。
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 コンソールで割り当てを表示する
リージョンごとの AWS 接続数 リージョンごとに 50 件の接続。 プロジェクトには、AWS リージョンごとに最大 50 件の AWS 接続を設定できます。
リージョンごとの Azure 接続数 リージョンごとに 50 件の接続。 プロジェクトには、Azure リージョンごとに最大 50 件の Azure 接続を設定できます。

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 以下にする必要があります。
インタラクティブ 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プレビュー)には、次の上限が適用されます。

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

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

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

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

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

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

IAM API

BigQuery で Identity and Access Management 機能を使用して IAM ポリシーの取得と設定を行い、IAM の権限をテストする場合、次の割り当てが適用されます。

割り当て デフォルト
1 分あたりの IamPolicy リクエスト数 3,000 件のリクエスト プロジェクトで 1 分あたり最大 3,000 件の IAM リクエストを送信できます。
Google Cloud コンソールで割り当てを表示する
1 分あたりのユーザーごとの IamPolicy リクエスト数 1,500 リクエスト 各ユーザーは、プロジェクトごとに 1 分あたり最大 1,500 件の IAM リクエストを送信できます。
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 useu のマルチリージョンでは、プロジェクトごとに最大 2,000 個の ReadRows 接続を同時に開くことができます。その他のリージョンでは最大 400 個の ReadRows 接続を同時に開くことができます。場合によっては、この上限よりも少ない同時接続数に制限されます。

Storage Write API

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

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

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

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

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

Java または Go でデフォルト ストリームを使用する場合、必要な全体的な接続数を減らすため、Storage Write API 多重化を使用して、共有接続を持つ複数の宛先テーブルに書き込むことをおすすめします。

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

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

また、割り当て使用量と上限をモニタリングするためのアラートを設定することもできます。

スループット マルチリージョンでは 3 GB/秒のスループット。リージョンで 300 MB/秒のスループット useu のマルチリージョンでは最大 3 GBps をストリーミングでき、プロジェクトごとに他のリージョンでは最大 300 MBps をストリーミングできます。
Google Cloud コンソールで割り当てを表示する

プロジェクトの割り当てと上限の指標は、Cloud Monitoring で確認できます。リージョンに基づいてスループット上限の名前を選択します。useu、その他のリージョンのオプションは、それぞれ AppendBytesThroughputPerProjectAppendBytesThroughputPerProjectEUAppendBytesThroughputPerProjectRegion です。

また、割り当て使用量と上限をモニタリングするためのアラートを設定することもできます。


CreateWriteStream リクエスト 1 リージョン、1 プロジェクトごとに 4 時間あたり 30,000 ストリーム CreateWriteStream は、リージョン、プロジェクトごとに 4 時間あたり最大 30,000 回呼び出すことができます。セマンティクスが 1 回だけの場合は、デフォルト ストリームの使用を検討してください。
Google Cloud コンソールで割り当てを表示する
保留中のストリーム バイト数 マルチリージョンでは 10 TB、リージョンでは 1 TB トリガーする commit ごとに、useu のマルチリージョンでは最大 10 TB を、他のリージョンでは最大 1 TB を commit できます。
Google Cloud コンソールで割り当てを表示する

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

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

ストリーミング挿入

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

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

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

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

必要に応じて、Cloud カスタマーケアに連絡して、割り当ての増加をリクエストできます。増加はできるだけ早く(必要になる少なくとも 2 週間前)にリクエストしてください。特に割り当てが大幅に増加した場合は、割り当ての増加に時間がかかります。

他のすべてのロケーションでプロジェクトごとの 1 秒あたりの最大バイト数 1 秒あたり 300 MB

プロジェクトでは、useu のマルチリージョン以外のすべてのロケーションで、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 エラーが発生します。

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