割り当てと上限
このドキュメントでは、BigQuery に適用される割り当てと上限について説明します。
割り当ては、Cloud プロジェクトで使用できる特定の共有 Google Cloud リソース（ハードウェア、ソフトウェア、ネットワーク コンポーネントなど）の量を制限します。
割り当てはシステムの一部で、次の機能があります。
- Google Cloud のプロダクトとサービスの使用量や消費量をモニタリングする。
- 公平性の確保や使用量急増の抑制などのため、これらのリソースの消費量を制限する。
- 規定の制限を自動的に適用する構成を維持する。
- 割り当ての変更を実施またはリクエストする手段を提供する。
割り当てを超過すると、ほとんどの場合、システムは関連する Google リソースへのアクセスをすぐにブロックするため、ユーザーが試行しているタスクは失敗します。ほとんどの場合、割り当ては各 Cloud プロジェクトに適用され、その 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 メソッドで送信されたジョブによって自動的に作成されるクエリジョブには、次の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| 同時実行インタラクティブ クエリの最大数 | 100 個のクエリ |
プロジェクトで最大 100 個の同時インタラクティブ クエリを実行できます。結果がクエリ キャッシュから返されたクエリは、BigQuery がキャッシュ ヒットどうかを判断するまで、この上限にカウントされます。ドライラン クエリは、この上限にカウントされません。ドライラン クエリを指定するには、--dry_run フラグを使用します。この上限に収める方法については、割り当てエラーのトラブルシューティングをご覧ください。
このようなエラーを減らす方法の 1 つは、クエリキューを有効にすることです（プレビュー）。クエリキューを有効にすると、同時実行の制限を動的に行うことができます。また、他のクエリの実行中に、最大 1,000 個のインタラクティブ クエリのキューイングを行うことができます。
|
| キューに追加できるインタラクティブ クエリの最大数 | クエリ 1,000 件 | クエリキュー（プレビュー版）が有効になっている場合、プロジェクトで最大 1,000 個のインタラクティブ クエリをキューに入れることができます。 この上限を超えるインタラクティブ クエリを追加しようとすると、割り当てエラーが返されます。 |
| 同時バッチクエリの最大数 | 10個のクエリ | プロジェクトでは、最大 10 個の同時バッチクエリを実行できます。 |
| キューに追加できるバッチクエリの最大数 | 20,000 クエリ | プロジェクトで最大 20,000 個のバッチクエリをキューに入れることができます。この上限を超えるバッチクエリを追加しようとすると、割り当てエラーが返されます。 |
| Cloud Bigtable 外部データソースに対する同時実行インタラクティブ クエリの最大数 | 16 個のクエリ | プロジェクトで、Bigtable 外部データソースに対して最大 16 個のクエリを同時に実行できます。 |
| リモート関数を含む同時クエリの最大数 | 10個のクエリ | プロジェクトごとにリモート関数を使用して最大 10 個のクエリを同時に実行できます。 |
| 同時実行の複数ステートメント クエリの最大数 | 1,000 件の複数ステートメント クエリ | 1 つのプロジェクトで、最大 1,000 件のマルチステートメント クエリを同時に実行できます。 |
| UDF を含むレガシー SQL 同時クエリの最大数 | 6 個のクエリ | プロジェクトで、ユーザー定義関数（UDF）を使用して最大 6 個のレガシー SQL クエリを同時に実行できます。この上限には、インタラクティブ クエリとバッチクエリの両方が含まれます。UDF を含むインタラクティブ クエリは、インタラクティブ クエリの同時実行の上限に対してもカウントされます。この上限は標準 SQL クエリには適用されません。 |
| 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 個まで参照できます。この上限には次のものが含まれます。
|
| 未解決レガシー SQL クエリの最大長 | 256 KB |
未解決レガシー SQL クエリは最大 256 KB までです。クエリが長い場合、「The query
is too large.」というエラーが表示されます。この上限内に収めるには、サイズの大きい配列またはリストをクエリ パラメータに置き換えることを検討してください。 |
| 未解決標準 SQL クエリの最大長 | 1 MB |
未解決標準 SQL クエリの最大長は 1 MB です。クエリが長い場合、「The query is too
large.」というエラーが表示されます。この上限内に収めるには、サイズの大きい配列またはリストをクエリ パラメータに置き換えることを検討してください。 |
| 解決済みレガシー SQL クエリと標準 SQL クエリの最大長 | 12 MB | 解決済みクエリの長さに対する上限では、クエリで参照しているすべてのビューとワイルドカード テーブルの長さも対象になります。 |
| 標準 SQL クエリ パラメータの最大数 | 10,000 個のパラメータ | 標準 SQL クエリには、最大 10,000 個のパラメータを含めることができます。 |
| リクエストの最大サイズ | 10 MB | リクエスト サイズは最大 10 MB です。これには、クエリ パラメータなどの追加のプロパティも含まれます。 |
| 最大レスポンス サイズ | 10 GB 圧縮 | このサイズは、データの圧縮率によって異なります。レスポンスの実際のサイズは、10 GB よりも大幅に大きくなることがあります。大規模なクエリ結果を宛先テーブルに書き込む場合、最大レスポンス サイズに上限はありません。 |
| BigQuery Omni のクエリ結果の最大サイズ | 非圧縮で 20 GiB | Azure データまたは AWS データをクエリする場合、結果の最大論理バイト数は 20 GiB です。詳しくは、BigQuery Omni の制限事項をご覧ください。 |
| 最大行数 | 100 MB | 行のサイズは行データの内部表現に基づくため、その最大サイズは概算値になります。行の最大サイズに対する上限は、クエリジョブ実行の特定の段階で適用されます。 |
| テーブル、クエリ結果、ビュー定義での最大列数 | 10,000 列 | テーブル、クエリ結果、ビュー定義には最大 10,000 列を含めることができます。 |
| BigQuery Omni クエリ結果のサイズ | 1 TB | プロジェクトの合計クエリ結果サイズは 1 日あたり 1 TB です。
詳細については、BigQuery Omni の制限をご覧ください。 |
| オンデマンド料金の同時実行スロットの最大数 | 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 Data Transfer Service の機能を使用しますが、このクエリは転送ではなく、読み込みジョブの上限の対象ではありません。
エクスポート ジョブ
bq コマンドライン ツール、Google Cloud コンソール、またはエクスポート タイプ jobs.insert API メソッドを使用して BigQuery からデータをエクスポートするジョブには、次の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| 1 日にエクスポートされる最大バイト数 | 50 TB |
共有スロットプールを使用すると、プロジェクトから 1 日あたり最大 50 TB のデータを無料でエクスポートできます。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 日あたりのテーブル オペレーションの上限にカウントされます。標準テーブルとパーティション分割テーブルの 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 に一致するファイルも含まれます）。 |
| 読み込みジョブの実行時間の上限 | 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 Console、bq コマンドライン ツール、または copy-type の jobs.insert API メソッドで作成されたジョブに適用されます。コピージョブは、それらが成功するか失敗するかにかかわらず、これらの上限にカウントされます。
| 上限 | デフォルト | メモ |
|---|---|---|
| 宛先テーブルごとの 1 日あたりコピージョブ数 | 1 日のテーブル オペレーションをご覧ください。 | |
| 1 日あたりのコピージョブ数 | 100,000 ジョブ | 1 日あたりプロジェクトで最大 100,000 個のコピージョブを実行できます。 |
| 宛先テーブルあたりの 1 日のリージョン間コピージョブの数 | 100 ジョブ | プロジェクトでは、宛先テーブルに対して 1 日あたり 100 個までのリージョン間コピージョブを実行できます。 |
| 1 日あたりのリージョン間コピージョブ | 2,000 ジョブ | プロジェクトで 1 日あたり最大 2,000 件のリージョン間コピージョブを実行できます。 |
データセットのコピーには、以下の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| コピー元データセット内の最大テーブル数 | 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 リージョンのスロットの合計数 | 2,000 スロット |
Google Cloud Console を使用して EU マルチリージョンで購入できる BigQuery スロットの最大数。 Google Cloud コンソール で割り当てを表示 |
| 米国リージョンのスロットの合計数 | 4,000 スロット |
Google Cloud Console を使用して米国マルチリージョンで購入できる BigQuery スロットの最大数。 Google Cloud コンソール で割り当てを表示 |
| 次のリージョンのスロット合計数: asia-northeast1、asia-northeast3、australia-southeast1、europe-west2、northamerica-northeast1 | 1,000 スロット |
Google Cloud Console を使用して、リストされた各リージョンで購入できる BigQuery スロットの最大数。 Google Cloud コンソール で割り当てを表示 |
| オムニリージョンのスロットの合計数（aws-us-east-1 および azure-eastus2） | 100 スロット |
Google Cloud Console を使用して、Omni リージョンで購入できる BigQuery スロットの最大数。 Google Cloud コンソール で割り当てを表示 |
| 他のすべてのリージョンのスロット合計数 | 500 スロット |
Google Cloud Console を使用して各リージョンで購入可能な BigQuery スロットの最大数。 Google Cloud コンソール で割り当てを表示 |
予約には次の上限が適用されます。
| 上限 | 値 | メモ |
|---|---|---|
| スロット予約の管理プロジェクトの数 | 組織あたり 5 プロジェクト | 特定のロケーション / リージョンでスロットにアクティブなコミットメントを含めることができる組織内のプロジェクトの最大数。 |
データセット
BigQuery データセットには、次の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| データセットの最大数 | 無制限 | 1 つのプロジェクトで保持できるデータセットの数に上限はありません。 |
| データセットあたりのテーブル数 | 無制限 | API 呼び出しを使用する場合、データセット内のテーブル数が 50,000 件に近づくと、列挙のパフォーマンスが低下します。Google Cloud コンソール では、データセットごとに最大 50,000 個のテーブルを表示できます。 |
| データセットのアクセス制御リストの承認済みリソースの数 | 2,500 個のリソース | データセットのアクセス制御リストには、合計最大 2,500 個の承認済みリソースを含めることができます。これには、承認済みビュー、承認済みデータセット、承認済み関数が含まれます。多数の承認済みビューが原因でこの上限を超える場合は、承認済みデータセットにビューをグループ化することを検討してください。 |
| 10 秒ごとのデータセットあたりデータセット更新オペレーションの数 | 5 個のオペレーション |
プロジェクトでは、10 秒ごとに最大 5 個のデータセット更新オペレーションを行うことができます。データセットの更新制限には、以下によって実行されるすべてのメタデータ更新オペレーションが含まれます。
|
| データセットの説明の最大長 | 16,384 文字 | データセットに説明を追加する場合、テキストは 16,384 文字以下で入力してください。 |
テーブル
すべてのテーブル
すべての BigQuery テーブルに次の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| 列の説明の最大文字数 | 1,024 文字 | 列に説明を追加する場合、テキストの文字数は 1,024 文字以下にしてください。 |
| ネストされたレコードの最大深度 | 15 レベル |
RECORD 型の列には、ネストされた RECORD 型（子レコードとも呼ばれる）を含めることができます。ネストの深さは最大 15 レベルに制限されます。この上限は、レコードがスカラーか配列ベース（繰り返し）かに依存しません。 |
標準テーブル
BigQuery の標準（組み込み）テーブルには、以下の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| 1 日あたりのテーブル変更 | 1,500 回の変更 |
プロジェクトでは、データの追加、データの更新、テーブルの切り捨てなど変更内容にかかわらず、1 日あたりテーブルごとに最大 1,500 件のテーブル変更を行うことができます。この上限は、宛先テーブルへのデータの追記や上書き、または DML DML ステートメントは 1 日あたりのテーブル変更の回数にカウントされますが、この上限によって制限されることはありません。 DML の上限の詳細については、データ操作言語のステートメントをご覧ください。 |
| テーブルあたりのテーブル メタデータ更新オペレーションの最大レート | 10 秒あたり 5 個のオペレーション |
プロジェクトで、テーブルごとに 10 秒あたり最大 5 個のテーブル メタデータ更新オペレーションを実行できます。この上限は、以下によって実行されるすべてのテーブル メタデータ更新オペレーションに適用されます。
この上限を超えると、 この上限にカウントされるオペレーションは、ログで確認できます。 |
| テーブルあたりの最大列数 | 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 に保存されているファイルサイズに適用されます（このサイズはクエリの料金設定式で使用されるサイズとは異なります）。外部のパーティション分割テーブルの場合、この上限はパーティションのプルーニング後に適用されます。 |
パーティション分割テーブル
BigQuery パーティション分割テーブルには、次の上限が適用されます。
パーティションの上限は、宛先パーティションに対して追記または上書きを行うか、DML DELETE、INSERT、MERGE、TRUNCATE TABLE、または UPDATE ステートメントを使用してテーブルのデータに影響する読み込みジョブ、コピージョブ、クエリジョブの合計に適用されます。
DML ステートメントはパーティションの上限までカウントされますが、それによって制限されません。DML の上限の詳細については、データ操作言語のステートメントをご覧ください。
1 つのジョブが複数のパーティションに影響することがあります。たとえば、DML ステートメントは（取り込み時間テーブルとパーティション分割テーブルの両方の）複数のパーティションでデータを更新できます。クエリジョブと読み込みジョブは、複数のパーティションに書き込みを行うこともできますが、対象はパーティション分割テーブルに限定されます。
BigQuery では、ジョブで消費される上限を決定する際に、ジョブの対象であるパーティションの数を使用します。ストリーミング挿入はこの上限に影響しません。
パーティション分割テーブルの制限内に収める方法については、割り当てエラーのトラブルシューティングをご覧ください。
| 上限 | デフォルト | メモ |
|---|---|---|
| パーティション分割テーブルあたりのパーティション数 | 4,000 個のパーティション | 各パーティション分割テーブルには、最大 4,000 個のパーティションを設定できます。この上限を超える場合は、パーティショニングに加えて、またはパーティショニングの代わりにクラスタリングの使用を検討してください。 |
| 1 つのジョブで変更されるパーティションの数 | 4,000 個のパーティション | 1 つのジョブ オペレーション（クエリまたは読み込み）で処理できるパーティションの数は最大 4,000 です。BigQuery では、4,000 個を超えるパーティションを変更しようとするクエリまたは読み込みジョブは拒否されます。 |
| 1 日の取り込み時間パーティション分割テーブルあたりのパーティションの変更回数 | 5,000 回の変更 | プロジェクトは、データの追加、データの更新、取り込み時間パーティション分割テーブルの切り捨てなど変更内容にかかわらず、1 日あたり最大 5,000 件のパーティション変更を行うことができます。 DML ステートメントは 1 日あたりのパーティション変更の回数にカウントされますが、この上限によって制限されることはありません。 DML の上限の詳細については、データ操作言語のステートメントをご覧ください。 |
| 1 日の列パーティション分割テーブルあたりのパーティション変更数 | 30,000 回の変更 |
プロジェクトで、列パーティション分割テーブルに対して 1 日あたり最大 30,000 回のパーティション変更を行うことができます。 |
| テーブルごとに 10 秒あたりの変更数 | 50 件の変更 | プロジェクトでは、10 秒ごとに最大 50 個の変更をパーティション分割テーブルごとに実行できます。 |
| 範囲パーティショニングが可能な範囲数 | 10,000 個の範囲 | 範囲パーティション分割テーブルには、最大 10,000 個の範囲を設定できます。この上限は、テーブルの作成時にパーティションの設定に適用されます。この上限は、テーブルの作成後に実際のパーティション数にも適用されます。 |
Table Snapshots
BigQuery のテーブル スナップショットには、次の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| 同時テーブル スナップショット ジョブの最大数 | 100 ジョブ | プロジェクトで最大 100 個のテーブル スナップショット ジョブを同時に実行できます。 |
| 1 日あたりのテーブル スナップショット ジョブの最大数 | 50,000 ジョブ | プロジェクトで、1 日に最大 50,000 個のテーブル スナップショット ジョブを実行できます。 |
| 1 日あたりのテーブル スナップショットごとの最大ジョブ数 | 50 ジョブ | プロジェクトで、テーブル スナップショットごとに 1 日あたり 50 個のジョブを実行できます。 |
| 10 秒間のテーブル スナップショットごとのメタデータ更新の最大数 | 5 回の更新 | プロジェクトで、テーブル スナップショットのメタデータを 10 秒ごとに最大 5 回まで更新できます。 |
ビュー
次の割り当てと上限は、ビューとマテリアライズド ビューに適用されます。
標準ビュー
BigQuery 標準ビューには次の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| ネストされたビューレベルの最大数 | 16 レベル |
BigQuery は最大 16 レベルまでのネストビューをサポートします。ネストレベルが 16 を超えると、INVALID_INPUT エラーが返されます。 |
| ビューの定義に使用される標準 SQL クエリの最大長 | 256,000 文字 | ビューを定義する標準 SQL クエリのテキストは、最大 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 |
組織のインデックスを持つテーブルの全体的なサイズが、リージョンの上限（US と EU のマルチリージョンで 100 TB。その他すべてのリージョンで 20 TB）を下回った場合、テーブルのインデックスを作成できます。インデックス管理ジョブが独自の予約で実行される場合、この上限は適用されません。 |
ルーティン
ルーティンには、以下の割り当てと上限が適用されます。
ユーザー定義の関数
Google 標準 SQL クエリに含まれる一時的および永続的なユーザー定義関数（UDF）には、次の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| 1 行あたりの最大出力 | 5 MB | 単一行の処理時に JavaScript UDF が出力できるデータの最大量は約 5 MB です。 |
| JavaScript UDF を使用した同時実行レガシー SQL クエリの最大数 | 6 個のクエリ | プロジェクトには、JavaScript で UDF を含むレガシー SQL クエリを同時に 6 個まで設定できます。この制限には、インタラクティブ クエリとバッチクエリの両方が含まれます。UDF を含むインタラクティブ クエリは、インタラクティブ クエリの同時実行レートの上限に対してもカウントされます。この上限は標準 SQL クエリには適用されません。 |
| クエリあたりの 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 Function 第 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 Function 第 1 世代には、個々の HTTP 呼び出しに独自の制限時間を設定できますが、最大制限時間は 9 分です。 Cloud Function 第 1 世代に設定された制限時間を超えると、上限回数の再試行後に HTTP 呼び出しの失敗とクエリの失敗が発生することがあります。 |
| HTTP 呼び出しの制限時間（Cloud Functions 第 2 世代または Cloud Run） | 20 分 | Cloud Function 第 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 を使用できます。ただし、以下のロケーションを除きます。
これらのロケーションでは、プロジェクトごとに各ロケーションに最大 500 の CPU を使用できます。 同じ地理的エリアにあるマルチリージョン ロケーションと単一リージョン ロケーションで同時にクエリを実行すると、クエリで同じ同時 CPU 割り当てが消費される可能性があります。 |
| 標準永続ディスクの最大合計サイズ | 204.8 TB | プロジェクトごとに、各ロケーションに最大 204.8 TB の標準永続ディスクを使用できます。 同じ地理的エリアにあるマルチリージョン ロケーションと単一リージョン ロケーションで同時にクエリを実行すると、クエリで同じ標準永続ディスク割り当てが消費される可能性があります。 |
データ操作言語
BigQuery のデータ操作言語（DML）ステートメントには、次の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| 1 日あたりの DML ステートメント数 | 無制限 |
DML ステートメントは、1 日あたりのテーブル変更回数（またはパーティション分割テーブルの場合、パーティション分割テーブルの 1 日あたりの変更回数）にカウントされます。ただし、プロジェクトで 1 日あたりに実行できる DML ステートメントの数は無制限であり、1 日あたりのテーブル変更回数（またはパーティション変更回数）の割り当てによる制限はありません。テーブルの変更（またはパーティション分割テーブルの変更）の 1 日あたりの上限を使い切ると、読み込みジョブやコピージョブなどの DML 以外の変更ではエラーが発生しますが、DML ステートメントはエラーを発生させずに実行できます。 たとえば、 mytable という取り込み時間パーティション分割テーブルがあるとします。mytable$20210720 にデータを追記する 3,000 件のコピージョブと INSERT を使用して mytable$20210720 にデータを追記する 2,000 件のクエリ DML ジョブを実行すると、パーティション変更の 1 日の上限に達します。この上限に達すると、それ以降のコピージョブは失敗しますが、DELETE、INSERT、MERGE、TRUNCATE TABLE、UPDATE ステートメントなどの DML に基づくクエリジョブは引き続き成功します。DML ステートメントには、注意すべき次の制限事項があります。 |
| テーブルごとの同時変更 DML ステートメント | 2 個のステートメント |
BigQuery では、テーブルごとに最大 2 個の同時変更 DML ステートメント（UPDATE、DELETE、MERGE）が実行されます。テーブルに対する追加の変更 DML ステートメントはキューに入ります。 |
| テーブルごとにキューに入る変更 DML ステートメント | 20 個のステートメント | 1 つのテーブルつき、最大 20 個の変更 DML ステートメントを実行待ちのキューに入れることができます。テーブルに追加の変更 DML ステートメントを送信すると、これらのステートメントは失敗します。 |
| DML ステートメントの最大キュー時間 | 6 時間 | インタラクティブの優先 DML ステートメントは、キューで最大 6 時間待機できます。6 時間が経過しても実行されない場合、ステートメントは失敗します。 |
変更 DML ステートメントの詳細については、INSERT DML の同時実行と UPDATE, DELETE, MERGE DML の同時実行をご覧ください。
複数ステートメント クエリ
BigQuery の複数ステートメント クエリには、以下の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| 累積の上限時間 | 24 時間 | 複数ステートメント クエリの累積の上限時間は 24 時間です。 |
| ステートメントの上限時間 | 6 時間 | 複数ステートメント クエリ内の個別のステートメントの上限時間は 6 時間です。 |
行レベルのセキュリティ
BigQuery の行レベルのアクセス ポリシーには次の上限が適用されます。
| 上限 | デフォルト | 注 |
|---|---|---|
| テーブルごとの行アクセス ポリシーの最大数 | 100 個のポリシー | テーブルでは、最大 100 個の行アクセス ポリシーを使用できます。 |
| クエリごとの行アクセス ポリシーの最大数 | 100 個のポリシー | 1 つのクエリで、最大 100 個の行アクセス ポリシーにアクセスできます。 |
10 秒あたりのポリシーごとの CREATE / DROP DDL ステートメントの最大数 |
5 個のステートメント |
10 秒以内に、行アクセス ポリシー リソースごとに最大 5 つの CREATE または DROP ステートメントを作成できます。 |
10 秒あたりのテーブルごとの DROP ALL ROW ACCESS POLICIES ステートメント |
5 個のステートメント |
プロジェクトで、10 秒以内にテーブルごとに最大 5 つの DROP ALL ROW ACCESS POLICIES ステートメントを作成できます。 |
データポリシー
列レベルの動的データ マスキングには、以下の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| ポリシータグごとのデータポリシーの最大数。 | 3 |
BI Engine
BigQuery BI Engine には次の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
| 1 つのロケーションのプロジェクトごとの最大予約サイズ（SQL インターフェース）。 | 250 GB | Looker Studio 以外のビジネス インテリジェンス（BI）ツールで BI Engine を使用する場合に適用されます。
プロジェクトの最大予約容量の増加をリクエストできます。予約の増加はほとんどのリージョンで利用でき、処理に 3 ～ 1 週間かかることがあります。 |
| 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,000 件のリスティングを作成できます。 |
| 共有データセットごとのリンク済みデータセットの最大数 | 1,000 リンク済みデータセット | すべての Analytics Hub サブスクライバーの合計には、共有データセットあたり最大 1,000 個のリンクされたデータセットを含めることができます。 |
API の割り当てと上限
これらの割り当てと上限は、BigQuery API リクエストに適用されます。
BigQuery API
以下の割り当てが BigQuery API（コア）リクエストに適用されます。
| 割り当て | デフォルト | メモ |
|---|---|---|
| 1 日あたりのリクエスト数 | 無制限 |
プロジェクトで、1 日に実行できる BigQuery API リクエストの数に制限はありません。 Google Cloud コンソール で割り当てを表示 |
1 分あたりの最大
tabledata.list バイト |
3.6 GB |
プロジェクトから tabledata.list を介して、1 分あたり最大 3.6 GB のテーブル行データを返すことができます。この割り当ては、読み取られるテーブルを含むプロジェクトに適用されます。その他の API（jobs.getQueryResults、jobs.query や jobs.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 コンソール で割り当てを表示 |
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 未満にする必要があります。 |
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 データポリシー API
Data Policy API（プレビュー）には、以下の上限が適用されます。
| 上限 | デフォルト | メモ |
|---|---|---|
dataPolicy.list呼び出しの最大数
|
1 プロジェクト、1 分あたり 400 回のリクエスト 組織あたり 1 分あたり 600 回のリクエスト |
|
dataPolicy.testIamPermissions呼び出しの最大数 |
1 プロジェクト、1 分あたり 400 回のリクエスト 組織あたり 1 分あたり 600 回のリクエスト |
|
| 読み取りリクエストの最大数。 |
1 プロジェクトあたり毎分 1,200 回のリクエスト 組織あたり毎分 1,800 回のリクエスト |
これには、dataPolicy.get と dataPolicy.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 |
us と eu のマルチリージョンでは、プロジェクトごとに最大 2,000 個の ReadRows 接続を同時に開くことができます。その他のリージョンでは最大 400 個の ReadRows 接続を同時に開くことができます。場合によっては、この上限よりも少ない同時接続数に制限されます。 |
Storage Write API
Storage Write API リクエストには、次の割り当てが適用されます。次の割り当ては、フォルダレベルで適用できます。これらの割り当ては、すべての子プロジェクトで集計、共有されます。この構成を有効にするには、Google サポートにお問い合わせください。
| 割り当て | デフォルト | メモ |
|---|---|---|
| 同時接続数 | マルチ リージョンでは 10,000、リージョンでは 1000 |
同時接続割り当ては、BigQuery データセット リソースを含むプロジェクトではなく、Storage Write API リクエストを開始するクライアント プロジェクトに基づきます。開始プロジェクトは、API キーまたはサービス アカウントに関連付けられたプロジェクトです。 「 プロジェクトの割り当てと上限の指標は、Cloud Monitoring で確認できます。リージョンに基づいて、同時接続の上限名を選択します。 |
| スループット | マルチリージョンでは 3 GB/秒のスループット。リージョンで 300 MB/秒のスループット |
us と eu のマルチリージョンでは最大 3 GBps をストリーミングでき、プロジェクトごとに他のリージョンでは最大 300 MBps をストリーミングできます。
Google Cloud コンソール で割り当てを表示 プロジェクトの割り当てと上限の指標は、Cloud Monitoring で確認できます。リージョンに基づいてスループット上限名を選択します。 |
CreateWriteStream リクエスト
|
プロジェクトごとに 4 時間あたり 30,000 ストリーム |
CreateWriteStream は、プロジェクトごとに 4 時間あたり最大 30,000 回呼び出すことができます。セマンティクスが 1 回だけの場合は、デフォルト ストリームの使用を検討してください。Google Cloud コンソール で割り当てを表示 |
| 保留中のストリーム バイト数 | マルチリージョンでは 10 TB：リージョンでは 1 TB |
トリガーする commit ごとに、us と eu のマルチリージョンでは最大 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 エラーが発生します。
| 上限 | デフォルト | メモ |
|---|---|---|
us と eu のマルチリージョンにおけるプロジェクトごとの 1 秒あたりの最大バイト数 |
毎秒 1 GB |
プロジェクトのストリーミングは 1 秒あたり最大 1 GB です。この割り当ては、特定のマルチリージョン内で累積的に処理されます。つまり、マルチリージョン内にある特定のプロジェクトのすべてのテーブルにストリーミングされる 1 秒あたりのバイト数の合計は 1 GB に制限されます。
この上限を超えると、 必要に応じて、Cloud カスタマーケアに連絡して割り当ての増加をリクエストできます。できるだけ早く、増加の必要の 2 週間前までに増加をリクエストしてください。特に割り当てが大幅に増加した場合は、割り当ての増加に時間がかかります。 |
| 他のすべてのロケーションでプロジェクトごとの 1 秒あたりの最大バイト数 | 1 秒あたり 300 MB |
プロジェクトでは、
この上限を超えると、 必要に応じて、Cloud カスタマーケアに連絡して割り当ての増加をリクエストできます。できるだけ早く、増加の必要の 2 週間前までに増加をリクエストしてください。特に割り当てが大幅に増加した場合は、割り当ての増加に時間がかかります。 |
| 最大行数 | 10 MB |
この値を超えると invalid エラーが発生します。 |
| HTTP リクエストのサイズ上限 | 10 MB |
この値を超えると 内部的に、リクエストは HTTP JSON から内部データ構造に変換されます。変換されたデータ構造には、独自のサイズ上限が適用されます。変換後の内部データ構造のサイズを予測することは困難ですが、HTTP リクエストを 10 MB 以下に保つと、内部上限に達する可能性は低くなります。 |
| リクエストあたりの最大行数 | 50,000 行 | 最大行数は 500 行をおすすめします。一括処理することでパフォーマンスとスループットをある程度向上させることはできますが、リクエストごとのレイテンシは高くなります。リクエストごとの行数が少なく、各リクエストにオーバーヘッドがあると取り込みの効率が下がります。また、リクエストごとの行数が多すぎるとスループットが下がります。代表的なデータ（スキーマとデータサイズ）を試して、データに最適なバッチサイズを決定します。 |
insertId フィールドの長さ |
128 文字 |
この値を超えると invalid エラーが発生します。 |
追加のストリーミング割り当てについては、割り当ての増加をリクエストするをご覧ください。