料金

BigQuery   |  BigQuery ML   |  BigQuery BI Engine   |  BigQuery Data Transfer Service

概要

BigQuery には、技術的なニーズと予算に合わせて選べるさまざまな料金オプションが用意されています。

ストレージの料金は、BigQuery に格納されているデータの量に基づいて計算されます。ストレージの料金は次のいずれかです。

• アクティブ - 過去 90 日間で変更された、テーブルまたはパーティション内のデータに対する月額料金。
• 長期 - テーブルまたはパーティションで、過去 90 日間で変更されていないデータに対する月額料金。料金は安めに設定されています。

クエリの料金については、次の 2 種類の料金モデルからお選びいただけます。

• オンデマンド - 最も柔軟なオプションです。オンデマンドの料金は、実行した各クエリで処理されたデータの量に基づいて計算されます。
• 定額 - この料金オプションは、費用を予測可能にしたいお客様に最適です。定額料金ではクエリ処理用の専用リソースを購入するため、個々のクエリについては課金されません。

ストレージとクエリの料金の詳細については、Google Cloud SKU をご覧ください。オンデマンド クエリの料金は、SKU ページに分析料金として記載されています。

特に指定のない限り、料金モデルは個別のプロジェクトではなくアカウントに適用されます。

料金の概要

次の表に BigQuery の料金を示します。BigQuery の割り当てと上限は、以下の各オペレーションに適用されます。

料金の請求方法

作成する各プロジェクトには、請求先アカウントが関連付けられます。プロジェクトで実行されている BigQuery ジョブによって発生する費用は、関連付けられている請求先アカウントに請求されます。BigQuery のストレージ料金も、関連付けられている請求先アカウントに請求されます。

請求データの分析方法

BigQuery の費用と傾向は、Cloud Console の Cloud Billing レポートページで確認できます。レポートを使用して請求データを分析する方法については、請求レポートと費用傾向の表示をご覧ください。

BigQuery で請求データを分析する方法については、Cloud Billing のドキュメントの Cloud Billing データを BigQuery にエクスポートするをご覧ください。

無料のオペレーション

次の表に、どのロケーションでも無料で使用できる BigQuery オペレーションを示します。BigQuery の割り当てと上限は、以下の各オペレーションに適用されます。

オペレーション	詳細
データの読み込み	Cloud Storage から、またはローカル ファイルから BigQuery へのデータの読み込みについては、課金されません。ただし、Cloud Storage へのデータの保存に対しては課金されます。詳しくは、Cloud Storage 料金ページのデータ ストレージをご覧ください。BigQuery に読み込んだデータは、BigQuery のストレージの料金の対象となります。 ターゲット データセットが US マルチリージョンに配置されている場合、他のリージョンの Cloud Storage バケットからの読み込み時にネットワーク（下り）トラフィックに対して課金されません。詳しくは、ロケーションに関する留意事項をご覧ください。
データのコピー	テーブルのコピーは無料ですが、新しいテーブルやコピーしたテーブルの保存には料金が発生します。詳しくは、既存のテーブルのコピーをご覧ください。
データのエクスポート	BigQuery から Cloud Storage にデータをエクスポートする場合、エクスポート オペレーションは無料ですが、Cloud Storage へのデータの保存では料金が発生します。詳しくは、Cloud Storage 料金ページのデータ ストレージをご覧ください。詳しくは、BigQuery からのデータのエクスポートをご覧ください。
データセットの削除	データセットの削除は無料です。
テーブル、ビュー、パーティション、関数の削除	テーブルの削除、ビューの削除、個々のテーブル パーティションの削除、ユーザー定義関数の削除は無料です。
メタデータ オペレーション	list、get、patch、update、delete の呼び出しは無料です。たとえば、データセットの一覧取得、データセットのアクセス制御リストの更新、テーブルの説明文の更新、データセット内のユーザー定義関数の一覧取得などが該当します（ただし、これらに限定されません）。
疑似列の読み取り	次の疑似列のコンテンツに対するクエリは無料です。 _TABLE_SUFFIX - ワイルドカード テーブルにクエリを実行する場合に使用します。 _PARTITIONDATE - 取り込み時間パーティション分割テーブルにクエリを実行する場合に使用します。 _PARTITIONTIME - 取り込み時間パーティション分割テーブルにクエリを実行する場合に使用します。 _FILE_NAME - 外部データソースに基づくテーブルにクエリを実行する場合に使用します。
メタテーブルの読み取り	次のメタテーブルのコンテンツに対するクエリは無料です。 __PARTITIONS_SUMMARY__ - パーティション分割テーブルまたは取り込み時間パーティション分割テーブルのパーティションに関するメタデータを取得する場合に使用します。 __TABLES_SUMMARY__ - データセットのテーブルとビューのメタデータを取得する場合に使用します。
UDF の作成、置換、呼び出し	永続的なユーザー定義関数（UDF）の作成、置換、呼び出しは無料です。

Always Free の使用上限

Google Cloud の無料枠の一部として、BigQuery では特定の上限まで無料でリソースを使用できるようになっています。これらの無料使用量上限は、無料トライアル期間中だけでなく、期間終了後も適用されます。使用量上限を超え、かつ無料トライアル期間を過ぎている場合は、このページで説明する料金体系に沿って課金されます。

リソース	1 か月あたりの無料使用量上限	詳細
ストレージ	毎月 10 GB まで無料。	BigQuery に格納されている BigQuery ML モデルとトレーニング データは BigQuery ストレージの無料枠に含まれます。
クエリ（分析）	処理されるクエリデータは毎月 1 TB まで無料。	BigQuery ML の予測関数、検査関数、評価関数を使用するクエリは BigQuery 分析の無料枠に含まれます。CREATE MODEL ステートメントを使用する BigQuery ML クエリは無料枠に含まれません。 大容量をご利用のお客様は、毎月の費用が一定の BigQuery 定額料金もご利用いただけます。
BigQuery ML の CREATE MODEL クエリ	CREATE MODEL ステートメントを使用するクエリで処理されるデータは、毎月 10 GB まで無料。	BigQuery ML の CREATE MODEL クエリは BigQuery 分析の無料枠の対象外であり、BigQuery ML の組み込みモデル（BigQuery 内でトレーニングされるモデル）にのみ適用されます。

クエリの料金

クエリの料金は、SQL コマンドとユーザー定義関数の実行、データ操作言語（DML）とデータ定義言語（DDL）のステートメントの認定にかかる費用を指します。

BigQuery では次の 2 種類の料金モデルからお選びいただけます。

• オンデマンド料金: 柔軟かつ効率的な料金モデルで、料金は実行したクエリに対してのみ発生します。
• 定額料金: 毎月の費用が固定で予測可能です。

デフォルトでは、オンデマンド料金モデルに沿って請求されます。課金モデルを変更して定額料金を選択するか、特定のプロジェクトとロケーションの組み合わせごとにオンデマンドと定額料金のいずれかを選択できます。

オンデマンド料金

オンデマンド料金では、BigQuery は 1 つの指標「処理されたバイト数」（読み取りバイト数とも呼ばれる）に基づいてクエリの料金を課金します。データを BigQuery に保存するか、Cloud Storage、ドライブ、Cloud Bigtable などの外部データソースに保存するかに関係なく、処理されたバイト数に基づいて料金が請求されます。オンデマンド料金は、使用量のみに基づいて計算されます。

オンデマンド クエリの料金は次のとおりです。

クエリ料金について次の点に注意してください。

• BigQuery ではカラム型データ構造が使用されています。選択した列で処理されたデータの合計容量に応じて課金されます。列ごとの合計データは、その列のデータ型に基づいて計算されます。データサイズの計算方法の詳細についてはデータサイズの計算をご覧ください。
• エラーが返されたクエリまたはキャッシュから結果が取得されたクエリに対しては料金が発生しません。
• 料金は MB 単位のデータ処理容量（端数は四捨五入）で決まります。クエリが参照するテーブルあたりのデータ最小処理容量は 10 MB、クエリあたりのデータ最小処理容量は 10 MB とします。
• 実行中のクエリジョブをキャンセルすると、そのクエリが完了した場合に発生する料金が全額課金される可能性があります。
• クエリを実行するときは、結果に LIMIT を明示的に設定している場合でも、選択した列にある処理されたデータに応じて課金されます。
• テーブルのパーティショニングとクラスタ化により、クエリで処理されるデータ量を削減できます。ベスト プラクティスとして、可能な限りパーティショニングとクラスタ化を行ってください。
• オンデマンド クエリの料金は、Google Cloud SKU ページに分析料金として記載されています。

オンデマンド クエリのコスト管理

BigQuery のコスト管理メカニズムを使用すると、クエリ料金に上限を設定できます。設定には次の方法があります。

• ユーザーレベルまたはプロジェクト レベルのカスタムコスト管理
• クエリで課金される最大バイト数

Cloud Storage データのクエリ

外部データソースに対してクエリを実行する場合、クエリによって読み取られたバイト数に基づいて料金が請求されます。詳細については、クエリの料金をご覧ください。Cloud Storage にデータを保存した場合も、請求の対象になります。詳しくは、Cloud Storage の料金をご覧ください。

Cloud Storage でのカラム型のクエリ

外部データが ORC または Parquet に保存されている場合、請求対象のバイト数は、BigQuery が読み取る列に限定されます。外部データソースからのデータ型がクエリによって BigQuery のデータ型に変換されるので、読み取られたバイト数は BigQuery のデータ型のサイズに基づいて計算されます。データ型の変換の詳細については、次のページをご覧ください。

• ORC 変換
• Parquet の変換

定額料金

BigQuery では、処理データの TB あたりオンデマンド料金よりもクエリの固定料金をご希望のお客様向けに定額料金をご用意しています。

定額料金を使用する場合、BigQuery Reservations から選択できます。

定額料金プランに加入する場合は、クエリ処理に使用するスロット コミットメント（BigQuery スロットの割り当て数）を購入します。クエリでこの容量を使用しても、処理されたバイト数に対しては請求されません。容量の需要がコミット済み容量を超過すると、BigQuery はスロットをキューに入れます。追加の料金はかかりません。BigQuery がクエリ処理でスロットをどのように活用しているかについては、スロットをご覧ください。

定額料金

• BigQuery ML、DML、DDL ステートメントなどのクエリ費用に適用されます。
• ストレージ、ストリーミングの取り込み、BI Engine のコストには適用されません。
• 購入した容量はリージョン リソースとなります。あるリージョンまたはマルチリージョンで購入したスロット コミットメントは、別のリージョンまたはマルチリージョンで使用することも、移行することもできません。
• プロジェクトあたりの同時割り当て数を増やすことができます。Google Cloud サポートにお問い合わせください。
• コミットメントは秒単位、月額、年額からお選びいただけます。
• 組織全体での共有が可能です。プロジェクトごとにスロット コミットメントを購入する必要はありません。
• 最小スロット数は 100 で、100 スロット単位で購入可能です。
• コミットメントが期限切れになるまで秒単位で課金されます。

注: 定額料金の購入においてオフライン契約を結んでいる場合は、ここに記載するプランとは詳細が異なる場合があります。Reservations をご利用の場合は営業担当者までお問い合わせください。

注: オンデマンド課金をご利用のお客様は、クエリ処理でスロットが 2,000 以上になることがたびたびあります。100 スロットの割り当てでは、クエリのパフォーマンスが低下する可能性があります。

月定額契約

次の表に、月間スロット コミットメントの費用を記載します。

年定額契約

次の表に、年間スロット コミットメントの費用を記載します。

Flex Slots: 短期間のコミットメント

Flex Slots は特殊なコミットメント タイプです。

• コミット期間は 60 秒のみです。
• その後はいつでも Flex Slots をキャンセルできます。
• コミットメントがデプロイされた期間に対してのみ、秒単位で課金されます。

Flex Slots は容量の可用性の影響を受けます。Flex Slots を購入しようとするとき、その購入が確実に成功するとは限りません。ただし、コミットメントの購入が成功すると、確保した容量はキャンセルするまで保証されます。

次の表に、Flex Slots コミットメントの費用を記載します。

Trial Slots（プロモーション）

注: Trial Slots を使用できるのは us と eu のマルチリージョンのみです。

2020 年 5 月 20 日に、BigQuery を初めてご利用いただくお客様や過去にご利用いただいていたお客様を対象に、BigQuery Trial Slots の限定プロモーションをご用意しました。対象のお客様は Trial Slots を購入することで、500 スロットを 6 か月間、大幅な割引料金でご利用いただけます。

Trial Slots には次の特徴があります。

• 6 か月間の契約が必須となります。
• 購入日から 182 日間はキャンセルできません。
• 購入できるのは 500 スロットのみです。
• 他のコミットメント タイプを購入し、Trial Slots と組み合わせてご利用いただけます。
• Trial Slots を使用できるのは US と EU のマルチリージョンのみです。
• Trial Slots は限定プロモーションのため、先着順でのご提供となります。
• Trial Slots と他のタイプのスロット コミットメントには、パフォーマンスや可用性の面で違いはありません。

Trial Slots は、次の資格要件を満たすお客様を対象としています。

• Google Cloud の新規のお客様で、BigQuery に登録される方
• Google Cloud の既存のお客様で、BigQuery に登録される方
• BigQuery の既存のお客様で、過去 3 か月間にわたって月間利用料金が $500 を超えていない方
• 会社のメールアドレスを使用して登録されるお客様
• 販売パートナーやディストリビュータからではなく、直接 Google から購入されたお客様

トライアルのスロットについて詳しくは、トライアルのスロットをご覧ください。

プロモーションへの参加をご希望される場合は、BigQuery Trial Slots プロモーション フォームに必要事項をご記入ください。5 営業日以内にご連絡いたします。

ストレージの料金

BigQuery にデータを読み込むと、データの保存に対して課金されます。ストレージの料金は、テーブルに格納されているデータの量（非圧縮状態でのデータ量）に基づいて計算されます。

データのサイズは、個々の列のデータ型に基づいて計算されます。データサイズの計算方法の詳細については、データサイズの計算をご覧ください。

アクティブ ストレージ

アクティブ ストレージの料金は次のとおりです。

ストレージの料金は、MB あたり、秒あたりで案分されます。例を示します。

• 100 MB を半月格納した場合、支払い額は $0.001（1/10 セント）です
• 500 GB を半月格納した場合、支払い額は $5 です
• 1 TB を 1 か月格納した場合、支払い額は $20 です

注: ストレージの使用量はギガバイト（GB）単位で計算されます。1 GB は 2³⁰ バイトで、ギビバイト（GiB）ともいいます。同様に、1 TB は 2⁴⁰ バイト（1,024 GB）です。

長期保存

連続する 90 日間にわたってテーブルが編集されていない場合、そのテーブルに対するストレージ料金は自動的に約 50% 値引きされます。テーブルを長期にわたって保存していても、パフォーマンス、耐久性、可用性などの各種機能性が損なわれることはありません。

分割テーブルの各パーティションには長期保存の料金が個別に適用されます。90 日間変更がなかったパーティションのデータは長期保存料金の対象となり、割引価格が適用されます。

長期保存の料金は次のとおりです。

そのテーブルを編集すると、価格は通常のストレージ価格に戻り、90 日間の無編集日数計数タイマーがゼロから始まります。次のようなテーブルのデータを変更する操作を行った時点で、このタイマーはリセットされます。

操作	詳細
テーブルへのデータの読み込み	宛先テーブルへのデータの追加や、宛先テーブルの上書きを行う読み込みまたはクエリジョブ。
テーブルへのデータのコピー	宛先テーブルへのデータの追加や、宛先テーブルの上書きを行うコピージョブ。
テーブルへのクエリ結果の書き込み	宛先テーブルへのデータの追加や、宛先テーブルの上書きを行うクエリジョブ。
データ操作言語（DML）の使用	DML ステートメントによるテーブルデータの変更。
データ定義言語（DDL）の使用	CREATE OR REPLACE TABLE DDL ステートメントによるテーブルの置換。
テーブルへのデータのストリーミング	tabledata.insertAll API 呼び出しを使用するデータの取り込み。

上記以外の次のような操作では、タイマーはリセットされません。

• テーブルのクエリ
• テーブルクエリのビューの作成
• テーブルからのデータのエクスポート
• テーブルのコピー（別の宛先テーブルへ）
• テーブル リソースのパッチ適用または更新

請求期間内に 90 日間のしきい値に達したテーブルの料金は、日割りで計算されます。

長期保存の料金が適用されるのは BigQuery ストレージのみです。Cloud Bigtable、Cloud Storage、ドライブなどの外部データソースには適用されません。

BigQuery Storage API の料金

BigQuery Storage API にはオンデマンド料金モデルがあり、読み取ったデータに対して料金が発生します。定額料金に登録されているお客様は、BigQuery Storage API を使用して、1 か月あたり最大 300 TB のデータを無料で読み取ることができます。1 か月あたりの読み取りが 300 TB を超えた場合は、オンデマンド料金で請求されます。

オンデマンド料金

オンデマンド料金では、BigQuery Storage API は ReadRows の呼び出しによって BigQuery ストレージから読み取ったバイト数に基づいて課金します。

読み取られたバイト数には、フィルタリングのために使用されたものの、ReadRows からの出力としては返されないデータが含まれます。一時テーブルから読み取られたデータには課金されません。

オンデマンドの BigQuery Storage API の料金は次のとおりです。

BigQuery Storage API 料金について次の点に注意してください。

• 課金は読み取られた合計データ量に基づいて行われます。1 列あたりの読み取られた合計データ量は、列内のデータ型に基づいて計算され、データのサイズは列のデータ型に基づいて計算されます。データサイズの計算方法の詳細については、データサイズの計算をご覧ください。
• ReadRows の呼び出しが失敗した場合でも、読み取りセッションで読み取られたデータに対して料金が発生します。
• ストリームの終わりに達する前に ReadRows の呼び出しをキャンセルした場合、キャンセル前に読み取られたデータに対して料金が発生します。ReadRows の呼び出しをキャンセルする前に読み取られたものの返されていないデータが、請求金額に含まれる可能性があります。
• ベスト プラクティスとして、可能な限りパーティション分割テーブルやクラスタ化テーブルを使用してください。WHERE 句を使用してパーティションをプルーニングすることによって、読み取るデータ量を減らすことが可能です。詳細については、パーティション分割テーブルのクエリをご覧ください。

データサイズの計算

BigQuery にデータを読み込むとき、またはデータのクエリを実行するときに、データサイズに応じて料金が発生します。データサイズは、各列のデータ型のサイズに基づいて計算されます。

保存されたデータのサイズとクエリで処理されたデータのサイズは、ギガバイト（GB）単位で計算されます。1 GB は 2³⁰ バイトで、ギビバイト（GiB）ともいいます。同様に、1 TB は 2⁴⁰ バイト（1,024 GB）です。

BigQuery のデータ型のサイズは次のとおりです。

データ型	サイズ
INT64/INTEGER	8 バイト
FLOAT64/FLOAT	8 バイト
NUMERIC	16 バイト
BIGNUMERIC（プレビュー）	32 バイト
BOOL/BOOLEAN	1 バイト
STRING	2 バイト + UTF-8 エンコードされた文字列のサイズ
BYTES	2 バイト + 値のバイト数
DATE	8 バイト
DATETIME	8 バイト
TIME	8 バイト
TIMESTAMP	8 バイト
STRUCT/RECORD	0 バイト + 含まれているフィールドのサイズ
GEOGRAPHY	16 バイト + 24 バイト × GEOGRAPHY 型の頂点の数（頂点の数は ST_NumPoints 関数で確認できます）

どのデータ型でも、null 値は 0 バイトとして計算されます。

繰り返し列は配列として格納され、サイズは値の個数に基づいて計算されます。たとえば、整数列（INT64）で繰り返しがあり（ARRAY<INT64>）、4 個のエントリを含む場合、32 バイト（4 エントリ × 8 バイト）として計算されます。

ストリーミング料金

BigQuery へのデータの読み込みは無料ですが、ストリーム データには若干の料金がかかります。

ストリーミング挿入の料金は次のとおりです。

データ操作言語の料金

BigQuery では、DML クエリで処理したバイト数に基づき、そのクエリに対して課金されます。

パーティション分割されていないテーブルの DML 料金

パーティション分割されていないテーブルの場合、処理されたバイト数は次のように計算されます。

DML ステートメント	処理されたバイト数
INSERT	クエリでスキャンしたテーブルによって参照されたすべての列で、処理された合計バイト数。
UPDATE	クエリでスキャンしたテーブルによって参照された、すべての列の合計バイト数 + UPDATE の開始時に更新されたテーブルの、すべての列の合計バイト数。
DELETE	クエリでスキャンしたテーブルによって参照された、すべての列の合計バイト数 + DELETE の開始時に変更されたテーブルの、すべての列の合計バイト数。
MERGE	MERGE ステートメントに INSERT 句のみがある場合、クエリでスキャンしたすべてのテーブルによって参照されたすべての列で、処理された合計バイト数に対して課金されます。 MERGE ステートメントに UPDATE 句または DELETE 句がある場合、クエリでスキャンしたソーステーブルによって参照されたすべての列で、処理された合計バイト数 + MERGE 開始時のターゲット テーブル内のすべての列の合計バイト数に対して課金されます。

パーティション分割テーブルの DML 料金

パーティション分割テーブルの場合、処理されたバイト数は次のように計算されます。

DML ステートメント	処理されたバイト数
INSERT	クエリでスキャンしたすべてのパーティションで、参照されたすべての列で処理された合計バイト数。
UPDATE	クエリでスキャンしたテーブルのすべてのパーティションで、参照されたすべての列で処理された合計バイト数 + UPDATE の開始時に更新されたテーブルで、更新またはスキャンされたパーティション内の、すべての列の合計バイト数。
DELETE	クエリでスキャンしたテーブルのすべてのパーティションで、参照されたすべての列で処理された合計バイト数 + DELETE の開始時に変更されたテーブルで、変更またはスキャンされたパーティション内の、すべての列の合計バイト数。
MERGE	MERGE ステートメントに INSERT 句のみがある場合、クエリでスキャンしたすべてのパーティションによって参照されたすべての列で、処理された合計バイト数に対して課金されます。 MERGE ステートメントに UPDATE 句または DELETE 句がある場合、クエリでスキャンしたソーステーブルのすべてのパーティションで参照されたすべての列で、処理された合計バイト数 + MERGE 開始時に、ターゲット テーブルで更新、削除、スキャンされたパーティション内のすべての列の合計バイト数に対して課金されます。

データ定義言語の料金

BigQuery では、DDL クエリで処理したバイト数に基づき、そのクエリに対して課金されます。DDL ステートメントで処理されるバイト数は、次のように計算されます。

DDL ステートメント	処理されたバイト数
CREATE TABLE	なし
CREATE TABLE ... AS SELECT ...	クエリでスキャンしたテーブルによって参照されたすべての列で、処理された合計バイト数。
CREATE VIEW	なし
DROP TABLE	なし
DROP VIEW	なし

クラスタ化テーブルの料金

BigQuery でクラスタ化テーブルを作成して使用する場合、テーブルに格納されるデータの量とデータに対して実行するクエリに基づいて料金が発生します。クラスタ化テーブルを使用すると、クエリで処理されないようにデータをプルーニングしてクエリのコストを抑えることができます。このプロセスはブロック プルーニングといいます。

ブロック プルーニング

BigQuery は、クラスタリング列の値に基づいてクラスタ化テーブルのデータを並べ替えて、データをブロックに整理します。

クラスタ化列のフィルタを含むクエリを送信すると、BigQuery はクラスタリング情報を使用して、クエリに関連するデータがブロックに含まれているかどうかを効率的に判断します。これにより、BigQuery は関連するブロックのみをスキャンできます。このプロセスをブロック プルーニングと呼びます。

クエリの料金は、処理されたバイト数に基づいて計算されます。クラスタ化テーブルにクエリを実行するときに、そのクエリにクラスタ化された列のフィルタが含まれている場合、BigQuery はフィルタ式とブロック メタデータを使用して、クエリでスキャンされるブロックをプルーニングします。

ブロックがプルーニングされると、スキャンの対象外となります。クエリで処理されたデータのバイト数を計算する際に、スキャンされたブロックのみが使用されます。クラスタ化テーブルに実行したクエリで処理されるバイト数は、スキャンされたブロック内で、クエリによって参照された各列から読み取られたバイト数の合計と等しくなります。

複数のフィルタを使用するクエリでクラスタ化テーブルが複数回参照された場合、BigQuery は、各フィルタによる該当するブロックの列のスキャンに対して課金します。

スクリプティングの料金

BigQuery スクリプトのベータ版をご利用の際には、意図しないクエリ費用の発生を避けるため、定額料金の予約をしているプロジェクトのご使用をおすすめします。スクリプトでスキャンされるバイト数が、スクリプトの実行前には不明であることが多いためです。BigQuery サンドボックスを使用して、制限付きの無料スクリプト実行のメリットを生かすこともおすすめします。今後、BigQuery チームは、スクリプトやスクリプト内の個別のステートメントでスキャンされる総バイト数に対するより明示的な制御機能を提供します。こちらはベータ版リリースです。料金の更新については BigQuery のリリースノートをご覧ください。

スクリプトが失敗すると、失敗までのステートメントの料金が引き続き適用されます。失敗したステートメントには課金されません。

SELECT、INSERT、UPDATE などの公開されているステートメントのタイプの場合、ステートメントの実行にかかる料金は公的価格設定のドキュメントに記載されています。スクリプティング固有のステートメントのタイプの場合、次の価格設定が適用されます。

• DECLARE: DEFAULT 式で参照されるテーブルに対してスキャンされたバイトの合計。テーブルを参照していない DECLARE ステートメントには課金されません。
• SET: 式で参照されるテーブルに対してスキャンされたバイトの合計。テーブルを参照していない SET ステートメントには課金されません。
• IF: 条件式で参照されるテーブルに対してスキャンされたバイトの合計。テーブルを参照していない IF 条件式には課金されません。実行されていない IF ブロック内のステートメントには課金されません。
• WHILE: 条件式で参照されるテーブルに対してスキャンされたバイトの合計。条件式のテーブルを参照していない WHILE ステートメントには課金されません。実行されていない WHILE ブロック内のステートメントには課金されません。
• CONTINUE または ITERATE: 関連費用はありません。
• BREAK または LEAVE: 関連費用はありません。
• BEGIN または END: 関連費用はありません。

スクリプトの実行でストレージが使用されていても、一時テーブルに料金は発生しません。ただし、一時テーブルを作成、変更、照会するステートメントには通常の料金がかかります。

BigQuery 料金の例

クエリ費用の見積もり

クエリ料金の例については、クエリ費用の見積もりをご覧ください。

ストレージ費用の見積もり

ストレージ料金の例については、ストレージ費用の見積もりをご覧ください。

パーティション分割されていないテーブルの DML 料金の例

パーティション分割されていないテーブルを変更する DML ステートメントで読み取ったバイト数を BigQuery が計算する方法を、以下の各例で示します。

例 1: パーティション分割されていないテーブルに対する UPDATE

table1 に INTEGER 型の col1 と STRING 型の col2 の 2 つの列があります。

UPDATE table1 SET col1 = 1 WHERE col2 = 2;

この例で処理されるバイト数 =

• col1 にあるバイト数の合計 +
• col2 にあるバイト数の合計

例 2: パーティション分割されていないテーブルに対する UPDATE

table1 に INTEGER 型の col1 と STRING 型の col2 の 2 つの列があります。table2 に INTEGER 型の field1 の 1 つの列があります。

UPDATE table1 SET col1 = 1 WHERE col1 in (SELECT field1 from table2)

この例で処理されるバイト数 =

• UPDATE 実行前の table1.col1 にあるバイト数の合計 +
• UPDATE 実行前の table1.col2 にあるバイト数の合計 +
• table2.field1 にあるバイト数の合計

パーティション分割テーブルの DML 料金の例

パーティション分割テーブルを変更する DML ステートメントで読み取ったバイト数を BigQuery が計算する方法を、以下の各例で示します。これらの例で使用されているテーブルの JSON スキーマ表現を表示するには、[DML ステートメントを使用したパーティション分割テーブルデータの更新] ページで、この例に使用されているテーブルをご覧ください。

例 1: 取り込み時間パーティション分割テーブルに対する INSERT

mytable2 に INTEGER 型の id と TIMESTAMP 型の ts の 2 つの列があります。mytable に INTEGER 型の field1 と STRING 型の field2 の 2 つの列があります。

INSERT INTO mytable (_PARTITIONTIME, field1) AS SELECT TIMESTAMP(DATE(ts)), id from mytable2

この例で処理されるバイト数 =

• mytable2.ts にあるバイト数の合計 +
• mytable2.id にあるバイト数の合計

行の挿入先となるテーブル mytable のサイズは、クエリのコストに影響しません。

例 2: パーティション分割テーブルに対する INSERT

mytable2 に INTEGER 型の id と TIMESTAMP 型の ts の 2 つの列があります。mycolumntable には、INTEGER 型の field1、STRING 型の field2、BOOLEAN 型の field3、TIMESTAMP 型の ts の 4 つの列があります。

INSERT INTO mycolumntable (ts, field1) AS SELECT ts, id from mytable2

この例で処理されるバイト数 =

• mytable2.ts にあるバイト数の合計 +
• mytable2.id にあるバイト数の合計

行の挿入先となるテーブル mycolumntable のサイズは、クエリのコストに影響しません。

例 3: 取り込み時間パーティション分割テーブルに対する UPDATE

DML ステートメント 1: 単一パーティションの更新

mytable2 に INTEGER 型の id と TIMESTAMP 型の ts の 2 つの列があります。mytable に INTEGER 型の field1 と STRING 型の field2 の 2 つの列があります。

UPDATE project.mydataset.mytable T SET T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

この例で処理されるバイト数 =

• mytable2.id にあるバイト数の合計 +
• "2017-05-01" パーティションの mytable.field1 にあるバイト数の合計 +
• "2017-05-01" パーティションの mytable.field2 にあるバイト数の合計

DML ステートメント 2: テーブル内のあるパーティションに基づく別のパーティションの更新

UPDATE project.mydataset.mytable T SET T._PARTITIONTIME = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT 1 from project.mydataset.mytable S WHERE S.field1 = T.field1 AND S._PARTITIONTIME = TIMESTAMP("2017-06-01") )

この例で処理されるバイト数 =

• "2017-05-01" パーティションの mytable.field1 にあるバイト数の合計 +
• "2017-05-01" パーティションの mytable.field2 にあるバイト数の合計 +
• "2017-06-01" パーティションの mytable.field1 にあるバイト数の合計 +
• "2017-06-01" パーティションの mytable.field2 にあるバイト数の合計

この場合、この UPDATE ステートメントのコストは、"2017-05-01" と "2017-06-01" に対応するパーティションにあるすべてのフィールドのサイズの合計です。

例 4: パーティション分割テーブルに対する UPDATE

DML ステートメント 1: 単一パーティションの更新

mytable2 に INTEGER 型の id と TIMESTAMP 型の ts の 2 つの列があります。mycolumntable には、INTEGER 型の field1、STRING 型の field2、BOOLEAN 型の field3、TIMESTAMP 型の ts の 4 つの列があります。

UPDATE project.mydataset.mycolumntable T SET T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

この例で処理されるバイト数 =

• mytable2.id にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.field1 にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.field2 にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.field3 にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.ts にあるバイト数の合計

DML ステートメント 2: テーブル内のあるパーティションに基づく別のパーティションの更新

UPDATE project.mydataset.mycolumntable T SET T.ts = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT 1 from project.mydataset.mycolumntable S WHERE S.field1 = T.field1 AND DATE(S.ts) = "2017-06-01")

この例で処理されるバイト数 =

• "2017-05-01" パーティションの mycolumntable.field1 にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.field2 にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.field3 にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.ts にあるバイト数の合計 +
• "2017-06-01" パーティションの mycolumntable.field1 にあるバイト数の合計 +
• "2017-06-01" パーティションの mycolumntable.field2 にあるバイト数の合計 +
• "2017-06-01" パーティションの mycolumntable.field3 にあるバイト数の合計 +
• "2017-06-01" パーティションの mycolumntable.ts にあるバイト数の合計

この場合、この UPDATE ステートメントのコストは、"2017-05-01" と "2017-06-01" に対応するパーティションにあるすべてのフィールドのサイズの合計です。

例 5: 取り込み時間パーティション分割テーブルに対する DELETE

mytable2 に INTEGER 型の id と TIMESTAMP 型の ts の 2 つの列があります。mytable に INTEGER 型の field1 と STRING 型の field2 の 2 つの列があります。

DELETE project.mydataset.mytable T WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

この例で処理されるバイト数 =

• mytable2.id にあるバイト数の合計 +
• "2017-05-01" パーティションの mytable.field1 にあるバイト数の合計 +
• "2017-05-01" パーティションの mytable.field2 にあるバイト数の合計

例 6: パーティション分割テーブルに対する DELETE

mytable2 に INTEGER 型の id と TIMESTAMP 型の ts の 2 つの列があります。mycolumntable には、INTEGER 型の field1、STRING 型の field2、BOOLEAN 型の field3、TIMESTAMP 型の ts の 4 つの列があります。

DELETE project.mydataset.mycolumntable T WHERE DATE(T.ts) =“2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

この例で処理されるバイト数 =

• mytable2.id にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.field1 にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.field2 にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.field3 にあるバイト数の合計 +
• "2017-05-01" パーティションの mycolumntable.ts にあるバイト数の合計

クラスタ化テーブルの料金の例

ClusteredSalesData という名前のクラスタ化テーブルがあります。テーブルは timestamp 列で分割され、customer_id 列でクラスタ化されています。データは次のブロックセットに編成されます。

パーティション ID	ブロック ID	ブロック内の customer_id の最小値	ブロック内の customer_id の最大値
20160501	B1	10000	19999
20160501	B2	20000	24999
20160502	B3	15000	17999
20160501	B4	22000	27999

このテーブルに次のクエリを実行します。このクエリでは、customer_id 列のフィルタが含まれています。

SELECT
  SUM(totalSale)
FROM
  `mydataset.ClusteredSalesData`
WHERE
  customer_id BETWEEN 20000
  AND 23000
  AND DATE(timestamp) = "2016-05-01"

このクエリは次の処理を行います。

• ブロック B2 と B4 の timestamp、customer_id、totalSale 列をスキャンします。
• timestamp パーティショニング列に対する DATE(timestamp) = "2016-05-01" というフィルタ述語があるため、B3 ブロックをプルーニングします。
• customer_id クラスタリング列に対する customer_id BETWEEN 20000 AND 23000 というフィルタ述語があるため、B1 ブロックをプルーニングします。

スクリプティングの料金の例

次のサンプル スクリプトには、以下のすべてのステートメントの上に、ステートメントの実行で発生する費用やその有無について説明しているコメントが含まれています。

-- No cost, since no tables are referenced.
DECLARE x DATE DEFAULT CURRENT_DATE();
-- Incurs the cost of scanning string_col from dataset.table.
DECLARE y STRING DEFAULT (SELECT MAX(string_col) FROM dataset.table);
-- Incurs the cost of copying the data from dataset.big_table.  Once the
-- table is created, you are not charged for storage while the rest of the
-- script runs.
CREATE TEMP TABLE t AS SELECT * FROM dataset.big_table;
-- Incurs the cost of scanning column1 from temporary table t.
SELECT column1 FROM t;
-- No cost, since y = 'foo' doesn't reference a table.
IF y = 'foo' THEN
  -- Incurs the cost of scanning all columns from dataset.other_table, if
  -- y was equal to 'foo', or otherwise no cost since it is not executed.
  SELECT * FROM dataset.other_table;
ELSE
  -- Incurs the cost of scanning all columns from dataset.different_table, if
  -- y was not equal to 'foo', or otherwise no cost since it is not executed.
  UPDATE dataset.different_table
  SET col = 10
  WHERE true;
END IF;
-- Incurs the cost of scanning date_col from dataset.table for each
-- iteration of the loop.
WHILE x < (SELECT MIN(date_col) FROM dataset.table) DO
  -- No cost, since the expression does not reference any tables.
  SET x = DATE_ADD(x, INTERVAL 1 DAY);
  -- No cost, since the expression does not reference any tables.
  IF true THEN
    -- LEAVE has no associated cost.
    LEAVE;
  END IF;
  -- Never executed, since the IF branch is always taken, so does not incur
  -- a cost.
  SELECT * FROM dataset.big_table;
END WHILE;