割り当てと上限

BigQuery のレート上限と割り当ての上限は以下のとおりです。

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

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

  • 一部の BigQuery の割り当ては Google Cloud Console に表示されます。これらの割り当てについては、Cloud Console を使用して割り当ての増加をリクエストできます。このプロセスの詳しい手順については、Google Cloud Console で割り当ての増加をリクエストする方法のチュートリアルをご覧ください。

    ガイドを表示

  • Google Cloud Console に表示されていない割り当ての増加をリクエストするには、Cloud カスタマーケアにお問い合わせください。

  • 一部の割り当てと上限を引き上げることはできません。たとえば、システムの安全保護対策を提供する割り当てや上限などです。

詳細については、割り当て上限の引き上げをリクエストするをご覧ください。

クエリジョブ

インタラクティブ クエリを実行することで自動的に作成されるクエリジョブと、jobs.query メソッドや query-type jobs.insert メソッドの呼び出しを使用してプログラムで送信されるジョブには、以下の各上限が適用されます。

  • インタラクティブ クエリに対する同時実行レート上限 - プロジェクトあたり同時実行クエリ 100 件

    結果がクエリ キャッシュから返されたクエリは、BigQuery がそれがキャッシュ ヒットであるかどうかを判断するのにかかる時間の間、この上限に対してカウントされます。ドライラン クエリは、この上限に対してカウントされません。ドライラン クエリを指定するには、--dry_run フラグを使用します。

    この上限内に収まる戦略については、割り当てエラーのトラブルシューティングをご覧ください。上限を引き上げるには、カスタマーケアまたは営業担当者にお問い合わせください。

  • Cloud Bigtable 外部データソースへのインタラクティブ クエリに対する同時実行レート上限 - 同時実行クエリ 4 件

    Bigtable 外部データソースに対する最大同時実行クエリ数は 4 です。

  • ユーザー定義関数(UDF)を含むレガシー SQL クエリに対する同時実行レート上限 - 同時実行クエリ 6 件

    UDF を含むレガシー SQL クエリに対する同時実行レート上限は、インタラクティブ クエリとバッチクエリの両方が対象になります。UDF を含むインタラクティブ クエリは、インタラクティブ クエリの同時実行レート上限に対してもカウントされます。この上限は標準 SQL クエリには適用されません。

  • クロス リージョンの連携クエリ - プロジェクトごとに 1 日あたり 1 TB

    BigQuery のクエリ処理のロケーションと Cloud SQL インスタンスのロケーションが異なる場合、クロス リージョンのクエリとなります。プロジェクトごとに 1 日あたり 1 TB までクロス リージョンのクエリを実行できます。 詳しくは、Cloud SQL 連携クエリをご覧ください。

  • 日次クエリサイズ上限 - デフォルトでは無制限

    カスタム割り当てを設定すると、ユーザーがクエリできるデータ量に対する上限を指定できます。

  • 宛先テーブルの日次更新回数上限 - テーブルごとに 1 日あたり 1,500 回の更新

    クエリジョブで宛先テーブルを更新できる回数には、1 日あたりテーブルごとに 1,500 回の上限があります。宛先テーブルの更新としてカウントされる対象としては、Cloud Console、bq コマンドライン ツールを使用したクエリ、または API の jobs.query メソッドや query-type jobs.insert メソッドの呼び出しによって実行される追加オペレーションや上書きオペレーションなどが挙げられます。

  • クエリ / スクリプト実行時間の上限 - 6 時間

    この上限を変更することはできません。ただし、場合によってはクエリを再試行できます。このとき、再試行されたクエリはさらに 6 時間実行でき、最大 3 回まで再試行できます。これにより、クエリの合計実行時間が 6 時間を超える場合があります。

  • 1 クエリあたりの参照可能テーブルの最大数 - 1,000

  • 未解決レガシー SQL クエリの最大長 - 256 KB

  • 未解決標準 SQL クエリの最大長 - 1 MB

  • 解決済みレガシー SQL クエリおよび標準 SQL クエリの最大長 - 12 MB

    解決済みクエリの長さに対する上限では、クエリで参照しているすべてのビューとワイルドカード テーブルの長さも対象になります。

  • 標準 SQL クエリ パラメータの最大数 - 10,000

  • 最大レスポンス サイズ - 10 GB(圧縮)

    このサイズは、データの圧縮率によって異なります。レスポンスの実際のサイズは、10 GB よりも大幅に大きくなることがあります。 大規模なクエリ結果を宛先テーブルに書き込む場合、最大レスポンス サイズに上限はありません。

  • 行の最大サイズ — 100 MB

    行のサイズは行データの内部表現に基づくことから、その最大サイズに対する上限は概算値です。行の最大サイズに対する上限は、クエリジョブ実行の特定の段階で適用されます。

  • テーブル、クエリ結果、ビュー定義での最大列数 - 10,000

  • オンデマンド料金における、1 プロジェクトあたりの同時実行スロットの最大数 - 2,000

    BigQuery スロットは、単一のプロジェクト内のすべてのクエリで共有されます。BigQuery が、クエリを高速化するためにこの上限を超えてバーストする場合があります。

    現在使用しているスロットの個数を確認するには、Cloud Monitoring を使用した BigQuery のモニタリングをご覧ください。

    SQL クエリでユーザー定義の関数に適用される上限については、UDF の上限をご覧ください。

  • オンデマンド 料金における、スキャンされたデータあたりの最大 CPU 使用率 - スキャンされる MiB あたり 256 CPU 秒

    オンデマンド料金では、スキャンされたデータ 1 MiB あたり約 256 CPU 秒まで使用できます。処理されるデータの量に対してクエリの CPU 負荷が高くなりすぎると、クエリは billingTierLimitExceeded エラーで失敗します。

    詳細については、billingTierLimitExceeded をご覧ください。

  • スケジュールされたクエリ

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

読み込みジョブ

以下の上限は、Cloud Console または bq コマンドライン ツールを使用してデータを読み込むときに自動的に生成されるジョブに適用されます。また、API の load-type jobs.insert メソッドを使用してプログラムで送信される読み込みジョブにも適用されます。

BigQuery にデータを読み込むときは、以下の各上限が適用されます。

  • テーブルごと 1 日あたりの読み込みジョブ数 - 1,500 個(失敗を含む)
  • プロジェクトごと 1 日あたりの読み込みジョブ数 - 100,000 個(失敗を含む)
  • 行とセルサイズの上限:
    データ形式 最大値
    CSV 100 MB(行およびセルサイズ)
    JSON 100 MB(行サイズ)
  • テーブルあたりの最大列数 - 10,000
  • 最大ファイルサイズ:
    ファイル形式 圧縮 非圧縮
    CSV 4 GB 5 TB
    JSON 4 GB 5 TB
  • 読み込みジョブ 1 件あたりの最大サイズ - CSV、JSON、Avro、Parquet、ORC のすべての入力ファイル全体で 15 TB
  • Avro ファイルのデータブロックの最大サイズ - 16 MB
  • ジョブ構成でのソース URI の最大数 - 10,000 個の URI
  • 読み込みジョブ 1 件あたりのファイル最大数 - 合計 1,000 万ファイル(すべてのワイルドカード URI に一致するすべてのファイルを含む)
  • 読み込みジョブ実行時間の上限 - 6 時間

米国に置かれたデータセットを除き、データの読み込みはデータセットのロケーションと同じリージョンにある Cloud Storage バケットから行う必要があります(このバケットは、マルチリージョン バケットまたはデータセットと同じリージョンにあるリージョン バケットとします)。米国に置かれたデータセットには任意のリージョンからデータを読み込むことができます。

更新が頻繁に発生するため、読み込みジョブの割り当てを定期的に超える場合は、BigQuery へのデータのストリーミングを検討してください。

詳細については、BigQuery へのデータの読み込みの概要をご覧ください。

コピージョブ

BigQuery でのテーブルのコピーには、以下の上限が適用されます。各上限は、bq コマンドライン ツールまたは Cloud Console を使用してデータをコピーするときに自動的に作成されるジョブに適用されます。また、jobs.insert API メソッドを使用してプログラムで送信されるコピージョブにも適用されます。

  • 宛先テーブルごとの 1 日あたりコピージョブ数 - 1,000(失敗を含む)

  • プロジェクトごと 1 日あたりのコピージョブ数 - 100,000(失敗を含む)

  • 宛先テーブルごとの 1 日あたりのクロスリージョン コピージョブ数 - 100(失敗を含む)

  • プロジェクトごとの 1 日あたりのクロスリージョン コピージョブ数 - 2,000(失敗を含む)

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

  • コピー元データセット内のテーブルの最大数 - 20,000

  • 同じリージョン内の宛先データセットにコピーできるテーブルの最大数 - 実行あたり 20,000

  • 異なるリージョン内のデータセットにコピーできるテーブルの最大数 - 実行あたり 1,000

    たとえば、8,000 個のテーブルを含むデータセットのリージョン間コピーを構成すると、BigQuery Data Transfer Service により 8 個の実行単位が順次自動的に作成されます。最初の実行で 1,000 個のテーブルがコピーされ、次回の 24 時間後の実行で次の 1,000 個のテーブルがコピーされるという形で、データセット内のすべてのテーブルがコピーされます。この方法で最大 20,000 個のテーブルを含むデータセットをコピーできます。

エクスポート ジョブ

BigQuery からデータをエクスポートするジョブには、以下の各上限が適用されます。各上限は、bq コマンドライン ツールまたは Cloud Console を使用してデータをエクスポートするときに自動的に作成されるジョブに適用されます。この上限はまた、エクスポート タイプの jobs.insert API メソッドを使用して、プログラムで送信されるエクスポート ジョブにも適用されます。
  • 1 日あたりのエクスポート数 - プロジェクトあたり最大エクスポート回数 100,000 回および 1 日あたり最大エクスポート容量 50 TB(50 TB のデータ上限は、すべてのエクスポート全体で累積した値に適用されます)
  • 1 日あたり 50 TB を超えるデータをエクスポートするには、Storage Read API または EXPORT DATA ステートメントを使用します。

  • ワイルドカード URI 数 - エクスポート 1 回あたり 500 個のワイルドカード URI

データセットの上限

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

  • 1 プロジェクトあたりのデータセット数 - 無制限

  • データセットあたりテーブル数 - 無制限

    API 呼び出しを使用する場合、データセット内のテーブル数が 50,000 件に近づくと、列挙のパフォーマンスが低下します。 Cloud Console では、データセットごとに最大 50,000 件のテーブルを表示できます。

  • データセットのアクセス制御リストでの承認済みビューの最大数 - 2,500

    承認済みビューを作成して、ソースデータへのアクセスを制限できます。承認済みビューは、そのビューに対してクエリを実行するユーザーに表示しない列を除外する SQL クエリを使用して作成します。データセットのアクセス制御リストには、最大で 2,500 件の承認済みビューを追加できます。

  • データセット メタデータ更新オペレーションの最大レート - データセットごとに 10 秒あたり 5 件のオペレーション

    データセット メタデータの更新に対する上限は、すべてのメタデータ更新オペレーションが対象です。これには、Cloud Console、bq コマンドライン ツール、クライアント ライブラリのいずれかを使用するもの、datasets.insertdatasets.patchdatasets.update のいずれかの API メソッドを呼び出すもの、または CREATE SCHEMAALTER SCHEMA DDL ステートメントのいずれかを実行するものが含まれます。

  • データセットの説明の最大文字数 - 16,384 文字

    データセットに説明を追加する場合、テキストは 16,384 文字以下で入力してください。

テーブルの上限

BigQuery テーブルには以下の各上限が適用されます。

すべてのテーブル

  • 列の説明の最大文字数 - 1,024 文字

    列に説明を追加する場合、テキストは 1,024 文字以下で入力してください。

  • ネストされたレコードの最大深度 - 15

    RECORD 型の列には、ネストされた RECORD 型(子レコードとも呼ばれる)を含めることができます。ネストの深さは最大 15 レベルに制限されます。この制限は、レコードがスカラーか配列ベース(繰り返し)かに依存しません。

標準テーブル

  • 1 日あたりのテーブル オペレーション最大数 - 1,500 件

    テーブルにデータを追記するオペレーションやテーブルを切り捨てるオペレーションを含め、どのようなオペレーションであっても、テーブルごとに実行できるオペレーションの総数は 1 日あたり 1,500 件に制限されています。

    テーブルに対するオペレーションの最大数は、宛先テーブルへのデータの追加や上書き、DML の INSERTUPDATEDELETEMERGE ステートメントを使用したテーブルへのデータの書き込みを実行するすべての読み込みジョブコピージョブクエリジョブを合わせた合計数が対象です。DML ステートメントはこの割り当てのカウントに含まれますが、それに制限されません。つまり、割り当てとしてカウントされる 1 日あたりのオペレーション数には DML ステートメントが含まれますが、DML ステートメントがこの上限により失敗することはないということです。

    たとえば、mytable にデータを追記する 500 件のコピージョブと mytable にデータを追記する 1,000 件のクエリジョブを実行すると、この割り当てに達します。

  • テーブル メタデータ更新オペレーションの最大レート - テーブルごとに 10 秒あたり 5 件のオペレーション

    テーブル メタデータ更新に対する上限は、すべてのメタデータ更新オペレーションが対象です。これには Cloud Console、bqコマンドライン ツールを使用するもの、または tables.inserttables.patchtables.update のいずれかの API メソッドを呼び出すもの、または ALTER TABLE DDL ステートメントを実行するものが含まれます。 この上限には、宛先テーブルに追加または上書きするすべての読み込みジョブ、コピージョブ、クエリジョブを合わせた合計数も含まれます。これは一時的なエラーで、指数バックオフを使用すると再試行できます。この上限は、DML オペレーションには適用されません。

  • テーブル、クエリ結果、ビュー定義での最大列数 - 10,000

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

  • パーティション分割テーブルごとのパーティション最大数 - 4,000

  • 1 つのジョブで変更できるパーティション最大数 - 4,000

    ジョブ オペレーション(クエリまたは読み込み)ごとに対象にできるパーティション数は最大 4,000 です。4,000 を超えるパーティションを対象とするクエリまたは読み込みジョブは、BigQuery で拒否されます。

  • 取り込み時間パーティション分割テーブルあたりの最大パーティション変更数 - 5,000

  • 列パーティション分割テーブルごとのパーティション最大変更数 - 30,000

    取り込み時間パーティション分割テーブルあたり合計 5,000 パーティション分割、列パーティション分割テーブルあたり 30,000 パーティションに制限されています。これらの上限内に収まる戦略については、割り当てエラーのトラブルシューティングをご覧ください。

    パーティションは、パーティション内でデータを追加または上書きするオペレーションを使用して変更できます。パーティションを変更するオペレーションの対象となるのは、読み込みジョブ、結果をパーティションに書き込むクエリ、パーティション内のデータを変更する DML ステートメント(INSERTDELETEUPDATEMERGE)などです。

    1 つのジョブで複数のパーティションに変更が加わる場合もあります。たとえば、DML ステートメントは(取り込み時間と分割テーブル両方の)複数のパーティションでデータを更新できます。クエリジョブと読み込みジョブは、複数のパーティションに書き込みを行うこともできますが、対象は分割テーブルのパーティションに限定されます。DML ステートメントはこの割り当てのカウントに含まれますが、それに制限されません。つまり、割り当てとしてカウントされる 1 日あたりのオペレーション数には DML ステートメントが含まれますが、DML ステートメントがこの上限により失敗することはないということです。

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

  • パーティション オペレーションの最大レート - テーブルあたり 10 秒ごとに 50 件のパーティション オペレーション

  • 範囲パーティショニングで可能な範囲の最大数 - 10,000

    この上限は、テーブルの作成時にパーティションの設定に適用されます。テーブルを作成すると、実際のパーティション数の上限も適用されます。

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

  • 同時テーブル スナップショット ジョブの最大数 - 100

    1 つのリージョンにつき、プロジェクトごとに最大 100 件のテーブル スナップショット ジョブを同時に実行できます。

  • 1 日あたりのテーブル スナップショット ジョブの最大数 - 50,000 件

    リージョンごと、プロジェクトごとに 1 日あたり最大 50,000 件のテーブル スナップショット ジョブを実行できます。

  • 1 日あたりのテーブル スナップショットごとの最大ジョブ数 - 50

    1 つのテーブル スナップショットで、1 日あたり最大 50 件のジョブを実行できます。上限値を引き上げるには、サポートまたは営業担当者にお問い合わせください。

  • 10 秒あたりのテーブル スナップショットごとのメタデータ更新の最大数 - 5

    1 つのテーブル スナップショットで、メタデータは 10 秒ごとに最大 5 回更新できます。

外部テーブル

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

  • 外部テーブルごとのソース URI の最大数 — 10,000 URI

  • 外部テーブルごとのファイルの最大数 — 合計 1,000 万ファイル(すべてのワイルドカード URI に一致するすべてのファイルを含む)

  • すべての入力ファイルで、Cloud Storage に保存できるデータの外部テーブルごとの最大サイズ — 600 TB

    この上限は、Cloud Storage に保存されているファイルサイズに適用されます(クエリの料金設定式で使用されるサイズとは異なります)。外部のパーティション分割テーブルの場合、この上限はパーティションのプルーニング後に適用されます。

テーブル関数の上限

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

  • テーブル関数名の最大文字数 - 256 文字
  • 引数の最大数 - 256
  • 引数名の最大文字数 - 128 文字
  • テーブル関数参照チェーンの最大深度 - 16
  • STRUCT 型の引数または出力の最大深度 - 15
  • STRUCT 型の引数または戻りテーブルに含まれるフィールドの 1 テーブル関数あたりの最大数 - 1,024
  • 戻りテーブルの最大列数 - 1,024
  • 戻りテーブルの列名の最大長 - 128
  • テーブル関数ごとの最大更新レート - 10 秒あたり 5 回テーブル関数の作成後、10 秒あたり 5 回まで各関数を更新できます。

データ操作言語(DML)ステートメント

BigQuery の DML ステートメントに割り当ての上限はありません。

ただし、DML ステートメントは 1 日あたりのテーブル オペレーションの数と 1 日あたりのパーティション変更の数にカウントされます。DML ステートメントがこの上限により失敗することはありません

行レベルのセキュリティ

Description 割り当て
テーブルごとの行アクセス ポリシーの最大数。 100
行アクセス ポリシーを持つテーブルに対してクエリで参照できる行アクセス ポリシーの合計数 100
CREATE / DROP DDL ステートメント テーブル上の行アクセス ポリシー リソースごとに 10 秒あたり 5 回
DROP ALL ROW ACCESS POLICIES ステートメント テーブル リソースごとに 10 秒あたり 5 回
行アクセス ポリシーの一覧表示(「rowAccessPolicies.list」REST API を使用) デフォルトの API 割り当て
行アクセス ポリシーの IAM ポリシーの取得(「rowAccessPolicies.getIamPolicy」API を使用) デフォルトの IAM API の割り当て

ストリーミング挿入

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

行の挿入時に insertId フィールドの値を設定しない場合、次の割り当てが適用されます。詳しくは、ベスト エフォート型の重複排除の無効化をご覧ください。 これは、ストリーミングの取り込み割り当て上限を引き上げるために BigQuery を使う場合に推奨される方法です。 これらの上限内に収まる戦略については、割り当てエラーのトラブルシューティングをご覧ください。

  • 1 秒あたりの最大バイト数: 1 GB

    挿入される各行の insertId フィールドに値を設定しない場合、1 つのプロジェクトにつき 1 秒あたり 1 GB に制限されます。この上限はプロジェクト レベルで適用されます。個々のテーブルには適用されません。

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

行の挿入時に insertId フィールドの値を設定する場合、次の割り当てが適用されます。

  • useu のマルチリージョンにおけるプロジェクトごと 1 秒あたりの最大行数: 50 万行

    挿入される各行の insertIdフィールドに値を設定する場合、useu のマルチリージョンでは、プロジェクトごとに 1 秒あたり 50 万行に制限されます。この割り当ては、特定のマルチリージョン内で累積的に処理されます。つまり、マルチリージョン内にある特定のプロジェクトのすべてのテーブルにストリーミングされる 1 秒あたりの行の合計は 50 万行に制限されます。また、各テーブルは 1 秒あたり 10 万行に制限されます。

    プロジェクトごとまたはテーブルごとの上限を超えると、quotaExceeded エラーが発生します。

  • 他のすべてのロケーションにおけるプロジェクトごと 1 秒あたりの最大行数: 10 万行

    挿入される各行の insertId フィールドに値を設定する場合、useu のマルチリージョン以外のすべてのロケーションでは、1 つのプロジェクトまたはテーブルにつき 1 秒あたり 10 万行に制限されます。この割り当ては、特定のリージョン内で累積的に処理されます。つまり、リージョン内にある特定のプロジェクトのすべてのテーブルにストリーミングされる 1 秒あたりの行の合計は 10 万行に制限されます。

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

  • テーブルごと 1 秒あたりの最大行数: 10万行

    挿入される各行の insertId フィールドに値を設定する場合、テーブルごとに 1 秒あたり 10 万行に制限されます。

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

  • 1 秒あたりの最大バイト数: 100 MB

    挿入される各行の insertId フィールドに値を設定する場合、1 つのテーブルにつき 1 秒あたり 100 MB に制限されます。

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

insertId フィールドに値を設定するかどうかに関係なく、次の追加のストリーミング割り当てが適用されます。

  • 行の最大サイズ: 10 MB

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

  • HTTP リクエストのサイズの上限: 10 MB(注を参照)

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

  • リクエストあたりの最大行数: リクエストごとに 50,000 行

    最大行数は 500 行をおすすめします。一括処理することでパフォーマンスとスループットをある程度向上させることができますが、リクエストごとのレイテンシは高くなります。リクエストごとの行数が少なく、各リクエストにオーバーヘッドがあると取り込みの効率が下がります。また、リクエストごとの行数が多すぎるとスループットが下がります。

    推奨される最大行数はリクエストごとに 500 行ですが、代表データ(スキーマとデータサイズ)を使用したテストを実施すると適切なバッチサイズを判断しやすくなります。

  • insertId フィールドの長さ: 128

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

プロジェクトでより多くのストリーミング割り当てが必要になった場合は、ベスト エフォート型の重複排除を無効にできます。制限値より多くの割り当てが必要になった場合は、Google Cloud Console からリクエストを送信できます。通常 2~3 営業日以内に回答を差し上げます。

UDF の上限

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

  • 単一行の処理時に JavaScript UDF が出力するデータの量 - およそ 5 MB 以下。
  • ユーザー定義関数(UDF)を含むレガシー SQL クエリに対する同時実行レート上限 - 同時実行クエリ 6 件
  • UDF を含むレガシー SQL クエリに対する同時実行レート上限は、インタラクティブ クエリとバッチクエリの両方が対象になります。UDF を使用したインタラクティブ クエリは、インタラクティブ クエリの同時実行レート上限に対してもカウントされます。この上限は標準 SQL クエリには適用されません。

  • クエリジョブで指定できる JavaScript UDF リソース(インライン コード blob または外部ファイルなど)の最大数 - 50 個
  • 各インライン コード blob のサイズの上限 - 32 KB
  • 各外部コードリソースの最大サイズ - 1 MB
永続的なユーザー定義関数には、以下の上限が適用されます。
  • 関数名の最大文字数 - 256 文字
  • 引数の最大数 - 256
  • 引数名の最大文字数 - 128 文字
  • ユーザー定義関数参照チェーンの最大深度 - 16
  • STRUCT 型の引数または出力の最大深度 - 15
  • STRUCT 型の引数または出力に含まれるフィールドの UDF あたりの最大数 - 1,024 個
  • クエリあたり、一意の UDF とテーブルの最大参照数 - 1,000

    完全に展開した後、各 UDF は一意のテーブルと UDF を合計 1,000 個まで参照できます。

  • CREATE FUNCTION ステートメントに含まれる JavaScript ライブラリの最大数 - 50 個
  • 含まれる JavaScript ライブラリパスの最大文字数 - 5,000 文字
  • UDF あたりの最大更新レート - 10 秒あたり 5 回

    作成した関数は、それぞれ 10 秒あたり 5 回まで更新できます。

  • 各行コード blob のサイズ上限は 32 KB です。
  • 各 JavaScript コードリソースの最大サイズ - 1 MB

ビューの上限

  • ネストしたビューレベルの最大数 - 16

    BigQuery は最大 16 レベルまでのネストビューをサポートします。ネストレベルが 16 を超えると、INVALID_INPUT エラーが返されます。

  • ビューの定義に使用する標準 SQL クエリの最大文字数 - 256,000 文字

    ビューを作成するときは、標準 SQL クエリのテキストは 256,000 文字以下にしてください。

  • データセットのアクセス制御リストでの承認済みビューの最大数 - 2,500

    承認済みビューを作成して、ソースデータへのアクセスを制限できます。承認済みビューは、そのビューに対してクエリを実行するユーザーに表示しない列を除外する SQL クエリを使用して作成します。データセットのアクセス制御リストには、最大で 2,500 件の承認済みビューを追加できます。

API リクエスト

すべての API リクエスト

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

  • ユーザーごと 1 秒あたりの API リクエスト数 - 100 件

    1 秒あたり 100 を超えるリクエストを発行すると、スロットリングが発生する可能性があります。この上限はストリーミング インサートには適用されません。

  • ユーザーごとの同時実行 API リクエスト数 - 300 件

    各ユーザーが 300 を超えるリクエストを同時に発行すると、スロットリングが発生する可能性があります。 この上限はストリーミング インサートには適用されません。

tabledata.list リクエスト

tabledata.list メソッドは、指定した行のセットからテーブルデータを取得します。jobs.getQueryResults を含む他の API、jobs.query および jobs.insert から生じるフェッチも、この API の割り当てを使用する場合があります。tabledata.list リクエストには、以下の上限が適用されます。

  • プロジェクトごとの tabledata.list クエリの最大数: 1,000 件/秒

    tabledata.list を呼び出すと、プロジェクトごとに 1 秒あたり最大 1,000 件のリクエストを送信できます。

  • tabledata.list の呼び出しによって返される、プロジェクトごと 1 秒あたりの最大バイト数: 60 MB/秒

    tabledata.list を呼び出すと、プロジェクトごとに 1 秒あたり最大 60 MB のテーブル行データを返すことができます。上限は、読み取られるテーブルを含むプロジェクトに適用されます。

  • tabledata.list の呼び出しによって返されるプロジェクトごとの 1 秒あたりの最大行数: 150,000/秒

    tabledata.list を呼び出すと、プロジェクトごとに 1 秒あたり最大 150,000 のテーブル行を返すことができます。上限は、読み取られるテーブルを含むプロジェクトに適用されます。

  • tabledata.list の呼び出しによって返される最大行数 - 100,000 行

    tabledata.list を呼び出すと、レスポンスに最大 100,000 のテーブル行を含めることができます。詳細については、API を使用した結果のページ分割をご覧ください。

tables.insert リクエスト

tables.insert メソッドは、空のテーブルをデータセットに新規作成します。tables.insert リクエストには、以下の上限が適用されます。

  • プロジェクトごとの 1 秒あたりの最大リクエスト数: 10

    tables.insert を呼び出すと、プロジェクトごとに 1 秒あたり最大 10 件のリクエストを作成できます。この上限には、CREATE TABLE DDL ステートメントなどのテーブルを作成するステートメントと、宛先テーブルに結果を書き込むクエリが含まれます。

projects.list リクエスト

projects.list メソッドは、アクセス権が付与されたすべてのプロジェクトを表示します。projects.list リクエストには、以下の上限が適用されます。

  • プロジェクトごとの 1 秒あたりの最大リクエスト数: 2

    projects.list を呼び出すと、プロジェクトごとに 1 秒あたり最大 2 件のリクエストを作成できます。

jobs.get リクエスト

jobs.get メソッドは、特定のジョブに関する情報を返します。jobs.get リクエストには、以下の上限が適用されます。

  • プロジェクトごとの 1 秒あたりの最大リクエスト数: 1,000

    jobs.get を呼び出すと、プロジェクトごとに 1 秒あたり最大 1,000 件のリクエストを作成できます。

jobs.query リクエスト

jobs.query メソッドは SQL クエリを同期的に実行し、指定したタイムアウト期間内にクエリが完了した場合はクエリ結果を返します。

  • レスポンスの最大サイズ - 10 MB

    デフォルトでは、結果のページあたりに返されるデータ行の最大行数は設定されていません。ただし、レスポンスの最大サイズは 10 MB に制限されています。返される行数は maxResults パラメータを使用して変更できます。

IAM API リクエスト

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

  • ユーザー 1 人あたりの最大リクエスト数 - 25

    プロジェクトごとにユーザー 1 人につき 1 秒あたり 25 件の IAM リクエストに制限されます。

  • プロジェクトあたりの最大リクエスト数 - 50

    プロジェクトごとに 1 秒あたり 50 件の IAM リクエストに制限されます。

プロジェクトでより多くの IAM 割り当てが必要になった場合は、Google Cloud Console からリクエストを送信できます。通常 2~3 営業日以内に回答を差し上げます。

BigQuery Storage Read API リクエスト

Storage Read API には、次の割り当てと上限が適用されます。

  • 最大行数上限 / フィルタの長さ: 1 MB

    Storage Read API の CreateReadSession 呼び出しを使用する場合、最大行制限 / フィルタの長さは 1 MB に制限されます。

  • データプレーン リクエストの読み取り - プロジェクトごとにユーザー 1 人につき 1 分あたり 5,000 回の呼び出し

    ReadRows の呼び出しは、プロジェクトごとにユーザー 1 人につき 1 分あたり 5,000 回に制限されます。

  • コントロール プレーン リクエストの読み取り - プロジェクトごとにユーザー 1 人につき 1 分あたり 5,000 回の呼び出し

    Storage Read API メタデータ オペレーションの呼び出し回数(CreateReadSessionSplitReadStream)は、プロジェクトごとにユーザー 1 人につき 1 分あたり合計 5,000 回に制限されます。

BigQuery Storage Write API リクエスト

Storage Write API には、次の割り当てと上限が適用されます。

  • 書き込みストリーム作成のレート上限: プロジェクトごとに 1 分あたり 100 回

    CreateWriteStream の呼び出しにはレート制限があります。この上限に達した場合は、指数バックオフでオペレーションを再試行します。また、CreateWriteStream の呼び出しを、一定の間隔で試行します。デフォルトのストリームはこの割り当ての対象になりません。コミットモードでデータの複製が不要な場合は、デフォルトのストリームの使用を検討してください。

  • 保留バイト数: プロジェクトごとに 100 GB

    この上限は、ストリームを commit する前に保留モードで書き込むことができる最大バイト数です。

  • 同時接続数: プロジェクトごとに 1,000

  • BatchCommitWriteStreams に渡されるストリームの最大数: 100

    保留モードでは、BatchCommitWriteStreams メソッドは commit するストリームのリストを取得します。この制限を超えると、メソッドからエラーが返されます。回避策として、BatchCommitWriteStreams を複数回呼び出します。

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

毎日の割り当ては、一日を通して一定の間隔で補充されます。割り当てによるレート上限の操作を調整するためです。割り当てを使い切った場合の分断が長時間にならないようにするためにも、断続的な更新が行われます。通常ほとんどの割り当ては、1 日に 1 回一斉に補充されるのではなく、数分以内に利用可能となるように補充されます。

トラブルシューティング

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

割り当て使用量の上限設定

特定のリソースの使用量を Google が指定する上限以下に制限する方法については、使用量の上限を設定するをご覧ください。