割り当てと上限

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

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

クエリジョブ

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

結果がクエリ キャッシュから返されたクエリと、ドライラン クエリは、この上限にカウントされません。ドライラン クエリを指定するには、--dry_run フラグを使用するか、クエリジョブで dryRun プロパティを設定します。

この上限はプロジェクト レベルで適用されます。上限値を引き上げるには、サポートまたは営業担当者にお問い合わせください。

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

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

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

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

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

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

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

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

  • クエリ実行時間の上限 - 6 時間

この上限を変更することはできません。

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

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

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

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

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

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

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

1 このサイズはデータの圧縮率によって異なります。レスポンスの実際のサイズは、10 GB よりも大幅に大きいことがあります。

大規模なクエリ結果を宛先テーブルに書き込む場合、最大レスポンス サイズに上限はありません。

  • 行の最大サイズ - 100 MB2

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

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

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

オンデマンド クエリに対するデフォルトの個数のスロットは、同じプロジェクトで実行するすべてのクエリで共有されます。一般的に、一度に処理するクエリの容量が 100 GB 未満であれば、2,000 個のスロットを使い切る可能性はほとんどありません。

現在使用しているスロットの個数を確認するには、Stackdriver を使用して BigQuery をモニタリングするをご覧ください。2,000 個を超えるスロットが必要な場合は、営業担当者にお問い合わせいただき、定額料金が適切かご相談ください。

  • Cloud Bigtable 外部データソースに対する最大同時クエリ - 4

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

読み込みジョブ

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

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

  • 1 日あたりのテーブルあたり読み込みジョブ数 - 1,000(失敗を含む)
  • 1 日あたりのプロジェクトあたり読み込みジョブ数 - 100,000(失敗を含む)
  • 1 日にテーブルごとに許可される読み込みジョブ数の上限(1,000 個)を引き上げることはできません。
  • 行とセルサイズの上限:
    データ形式 最大値
    CSV 100 MB(行およびセルサイズ)
    JSON 100 MB(行サイズ)
  • テーブルあたりの最大列数 - 10,000
  • 最大ファイルサイズ:
    ファイル形式 圧縮 非圧縮
    CSV 4 GB 5 TB
    JSON 4 GB 5 TB
    Avro 圧縮 Avro ファイルはサポート対象外ですが、圧縮データブロックはサポート対象です。BigQuery は DEFLATE および Snappy コーデックをサポートします。 5 TB(ファイル ヘッダー用に 1 MB)
  • 読み込みジョブ 1 件あたりの最大サイズ - CSV、JSON、Avro、Parquet、ORC のすべての入力ファイル全体で 15 TB
  • ジョブ構成でのソース URI の最大数 - 10,000 個の URI
  • 読み込みジョブ 1 件あたりのファイル最大数 - ワイルドカード URI に一致するすべてのファイルを含むファイル全体で 1,000 万
  • 読み込みジョブ実行時間の上限 - 6 時間
  • 米国に置かれたデータセットを除き、データの読み込みはデータセットのロケーションと同じリージョンにある Cloud Storage バケットから行う必要があります(このバケットは、マルチリージョン バケットまたはデータセットと同じリージョンにあるリージョン バケットとします)。米国に置かれたデータセットには任意のリージョンからデータを読み込むことができます。

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

コピージョブ

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

  • 1 日あたりの宛先テーブルあたりコピージョブ数 - 1,000(失敗を含む)
  • 1 日あたりのプロジェクトあたり読み込みジョブ数 - 100,000(失敗を含む)

エクスポート ジョブ

BigQuery からデータをエクスポートするジョブには、以下の各上限が適用されます。各上限は、コマンドライン ツール、コンソール、従来の BigQuery ウェブ UI を使用してデータをエクスポートすることで自動的に作成されるジョブに適用されます。また、API の load-type jobs.insert メソッドを使用してプログラムで送信されるエクスポート ジョブにも適用されます。

  • 1 日あたりのエクスポート数 - プロジェクトあたり最大エクスポート回数 100,000 回および 1 日あたり最大エクスポート容量 10 TB(10 TB のデータ上限は、すべてのエクスポート全体で累積した値に適用されます)
  • 1 日あたり 10 TB を超えるデータをエクスポートするには、BigQuery Storage API を使用します。

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

データセットの上限

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

  • プロジェクトあたりデータセット数 - 無制限
    プロジェクトあたりのデータセット数に上限はありませんが、1 つのプロジェクトで扱うデータセットが数千個になると、従来のウェブ UI のパフォーマンスが低下し始め、データセットのリスト表示の速度が遅くなります。
  • データセットあたりテーブル数 - 無制限
    データセット内のテーブル数が 50,000 個に近くなると、テーブルの列挙が遅くなります。API 呼び出しと従来の BigQuery ウェブ UI のどちらの場合も列挙のパフォーマンスは低下します。現在、GCP Console の BigQuery ウェブ UI で表示できるテーブル数は、データセットあたり 50,000 までです。従来の BigQuery ウェブ UI のパフォーマンスを向上させるには、?minimal パラメータを使用して、表示するテーブルの数をプロジェクトあたり 30,000 に制限します。このパラメータは、従来の BigQuery ウェブ UI の URL に次の形式で追加します。https://bigquery.cloud.google.com/queries/[PROJECT_NAME]?minimal
  • データセットのアクセス制御リストでの承認済みビューの最大数 - 2,500
    承認済みビューを作成して、ソースデータへのアクセスを制限できます。承認済みビューは、そのビューに対してクエリを実行するユーザーに表示しない列を除外する SQL クエリを使用して作成します。データセットのアクセス制御リストには、最大で 2,500 件の承認済みビューを追加できます。
  • データセット メタデータ更新オペレーションの最大レート - データセットあたり 10 秒ごとに 5 件のオペレーション
    データセット メタデータ更新に対する上限は、コンソール、従来の BigQuery ウェブ UI、bq コマンドライン ツールを使用するか、datasets.insertdatasets.patchdatasets.update のいずれかの API メソッドを呼び出して実行するすべてのメタデータ更新オペレーションが対象です。
  • データセットの説明の最大文字数 - 16,384 文字
    データセットに説明を追加する場合、テキストは 16,384 文字以下で入力してください。

テーブルの上限

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

すべてのテーブル

  • 列の説明の最大文字数 - 16,384 文字

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

標準テーブル

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

テーブルにデータを追記するオペレーション、テーブルを上書きするオペレーション、DML の INSERT ステートメントを使用してテーブルにデータを書き込むオペレーションも含め、どのようなオペレーションであっても、1 日あたりでテーブルに対して実行できるオペレーションの総数は 1,000 件に制限されています。

テーブルに対するオペレーションの最大数は、宛先テーブルへのデータの追加や上書き、DML の INSERT ステートメントを使用したテーブルへのデータの書き込みを実行するすべての読み込みジョブコピージョブクエリジョブを合わせた合計数が対象です。

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

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

テーブル メタデータ更新に対する上限は、GCP Console、従来の BigQuery ウェブ UI、bq コマンドライン ツール、クライアント ライブラリを使用するか、tables.inserttables.patchtables.update のいずれかの API メソッドを呼び出して実行するすべてのメタデータ更新オペレーションが対象です。この上限はジョブ出力にも適用されます。

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

分割テーブル

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

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

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

  • テーブルごとの 1 日あたりの最大パーティション変更数 - 5,000

分割テーブルでは 1 日あたりのパーティション変更の合計が 5,000 に制限されています。パーティションは、パーティション内でデータを追加または上書きするオペレーションを使用して変更できます。パーティションを変更するオペレーションの対象となるのは、読み込みジョブ、結果をパーティションに書き込むクエリ、パーティション内のデータを変更する DML ステートメント(INSERTDELETEUPDATEMERGE)などです。

1 つのジョブで複数のパーティションを対象にすることができます。たとえば、DML ステートメントは(取り込み時間と分割テーブル両方の)複数のパーティションでデータを更新できます。クエリジョブと読み込みジョブは、複数のパーティションに書き込みを行うこともできますが、対象はパーティション分割テーブルのパーティションに限定されます。BigQuery では、ジョブで消費される割り当て量を決定する際に、ジョブの対象であるパーティションの数を使用します。ストリーミング挿入はこの割り当てに影響しません。

  • パーティションに対するオペレーションの最大レート - 10 秒ごとに 50 件のパーティション オペレーション

ビューの上限

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

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

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

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

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

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

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 です。
  • JavaScript のビット演算は上位 32 ビットのみ処理します。

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

データ操作言語(DML)ステートメントには以下の上限が適用されます。

  • テーブルごとの INSERT、UPDATE、DELETE、MERGE の各ステートメントを合わせた 1 日あたりの最大数 - 1,000

MERGE ステートメントは、複数の INSERT 句、UPDATE 句、DELETE 句が使用されていても、単一の DML ステートメントとしてカウントします。

ストリーミング挿入

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

行の挿入時に insertId フィールドに値を設定しない場合:

現在、これらの割り当ては US マルチリージョン ロケーションにのみ適用されるため、使用するには BigQuery ストリーミング V2 ベータ版の登録フォームに入力する必要があります。

  • 1 秒あたりの最大行数: 100 万行
    挿入される各行の insertId フィールドに値を設定しない場合、1 つのプロジェクトにつき 1 秒あたり 100 万行に制限されます。この割り当ては累積的に処理されます。この割り当ては 1 つのテーブルで使用することも、プロジェクト内の複数のテーブルにデータをストリーミングするために使用することもできます。

    この制限を超えると quotaExceeded エラーが発生します。
  • 1 秒あたりの最大バイト数: 1 GB
    挿入される各行の insertId フィールドに値を設定しない場合、1 つのプロジェクトにつき 1 秒あたり 1 GB に制限されます。この制限はプロジェクト レベルで適用されます。個々のテーブルには適用されません。

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

行の挿入時に insertId フィールドの値を設定する場合:

  • 1 秒あたりの最大行数: 100 万行
    挿入される各行の insertId フィールドに値を設定する場合、1 つのプロジェクトまたはテーブルにつき 1 秒あたり 100 万行に制限されます。この割り当ては累積的に処理されます。この割り当ては 1 つのテーブルで使用することも、プロジェクト内の複数のテーブルにデータをストリーミングするために使用することもできます。

    この制限を超えると quotaExceeded エラーが発生します。
  • 1 秒あたりの最大バイト数: 100 MB
    挿入される各行の insertId フィールドに値を設定する場合、1 つのテーブルにつき 1 秒あたり 100 MB に制限されます。

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

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

  • 行の最大サイズ: 1 MB
    この値を超えると invalid エラーが発生します。
  • HTTP リクエストのサイズの上限: 10 MB
    この値を超えると invalid エラーが発生します。
  • リクエストあたりの最大行数: リクエストごとに 10,000 行
    最大行数は 500 行をおすすめします。一括処理することでパフォーマンスとスループットをある程度向上させることはできますが、リクエストごとのレイテンシは高くなります。リクエストごとの行数が少なく、各リクエストにオーバーヘッドがあると取り込みの効率が下がります。また、リクエストごとの行数が多すぎるとスループットが下がります。

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

プロジェクトでより多くのストリーミング割り当てが必要になった場合は、Google Cloud Platform Console からリクエストを送信できます。 ストリーミング データに対するカスタム割り当てを 50,000 行単位で設定できます。通常 2~3 営業日以内に回答を差し上げます。

API リクエスト

すべての API リクエスト

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

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

tabledata.list リクエスト

tabledata.list メソッドは、指定した行のセットからテーブルデータを取得します。tabledata.list リクエストには以下の各上限が適用されます。

  • プロジェクトごとの tabledata.list クエリの最大数: 500/秒
    tabledata.list を呼び出すと、プロジェクトごとに 1 秒あたり最大 500 のリクエストを送信できます。
  • tabledata.list の呼び出しによって返されるプロジェクトごとの 1 秒あたりの最大バイト数: 60 MB/秒
    tabledata.list を呼び出すと、プロジェクトごとに 1 秒あたり最大 60 MB のテーブル行データを返すことができます。上限は、読み取られるテーブルを含むプロジェクトに適用されます。
  • tabledata.list の呼び出しによって返されるプロジェクトごとの 1 秒あたりの最大行数: 150,000/秒
    tabledata.list を呼び出すと、プロジェクトごとに 1 秒あたり最大 150,000 のテーブル行を返すことができます。上限は、読み取られるテーブルを含むプロジェクトに適用されます。

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 パラメータを使用して変更できます。

BigQuery Storage API リクエスト

BigQuery Storage API を使用した ReadRows 呼び出しには、次の上限が適用されます。

  • 1 分あたりの ReadRows の呼び出し回数: 5,000 BigQuery Storage API を使用してデータを読み取る場合、ReadRows の呼び出し回数は、プロジェクトごとにユーザー 1 人につき 1 分あたり 5,000 回に制限されます。

BigQuery Storage API を使用した他のすべてのメソッドの呼び出しには、次の上限が適用されます。

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

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

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

エラーコード

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

このページは役立ちましたか?評価をお願いいたします。

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

ご不明な点がありましたら、Google のサポートページをご覧ください。