BigQuery の料金

BigQuery の料金については、こちらのページをご覧ください。

BigQuery ML については、BigQuery ML の料金ページをご覧ください。

BigQuery Data Transfer Service については、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 のドキュメントBigQuery への課金データのエクスポートをご覧ください。

無料のオペレーション

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

オペレーション 詳細
データの読み込み

Cloud Storage から BigQuery へのデータの読み込みは無料ですが、Cloud Storage へのデータの保存では料金が発生します。詳しくは、Cloud Storage 料金ページのデータ ストレージをご覧ください。BigQuery に読み込んだデータは、BigQuery のストレージの料金体系の対象となります。詳しくは、BigQuery へのデータの読み込みをご覧ください。

BigQuery でデータセットを作成するときは、データのロケーションを選択する必要があります。US を選択すると、他のリージョンにある Cloud Storage バケットからデータセットのテーブルにデータを読み込むことができます。現在のところ、米国以外のリージョンのデータを米国のデータセットに読み込む場合には、インターネット下りの料金は発生しません。

US 以外のロケーションを選択する場合は、次のいずれかを行う必要があります。

  • そのリージョンの Cloud Storage バケット(マルチリージョン バケット、またはデータセットと同じリージョンにあるリージョン バケット)からデータを読み込みます。
  • そのリージョンのバケットにデータをコピーします。

ある Cloud Storage リージョンから別の Cloud Storage リージョンにデータをコピーすると、Cloud Storage のネットワークの料金体系が適用されます。

データのコピー テーブルのコピーは無料ですが、新しいテーブルやコピーしたテーブルの保存には料金が発生します。詳しくは、既存のテーブルのコピーをご覧ください。
データのエクスポート BigQuery から Cloud Storage にデータをエクスポートする場合、エクスポート オペレーションは無料ですが、Cloud Storage へのデータの保存では料金が発生します。詳しくは、Cloud Storage 料金ページのデータ ストレージをご覧ください。詳しくは、BigQuery からのデータのエクスポートをご覧ください。
データセットの削除 データセットの削除は無料です。
テーブル、ビュー、パーティション、関数の削除 テーブルの削除、ビューの削除、個々のテーブル パーティションの削除、ユーザー定義関数の削除は無料です。
メタデータ オペレーション list、get、patch、update、delete の呼び出しは無料です。たとえば、データセットの一覧表示、データセットのアクセス制御リストの更新、テーブル説明の更新、データセット内のユーザー定義関数の一覧表示などが該当します(ただし、これらに限定されません)。
疑似列の読み取り 次の擬似列のコンテンツに対するクエリは無料です。
_TABLE_SUFFIX - ワイルドカード テーブルにクエリを実行する場合や、標準 SQL でテーブル デコレータのセマンティクスを実現する場合に使用します。 _PARTITIONDATE - 取り込み時間パーティション分割テーブルにクエリを実行する場合に使用します。 _PARTITIONTIME - 取り込み時間パーティション分割テーブルにクエリを実行する場合に使用します。 _FILE_NAME - 外部データソースに基づいてテーブルにクエリを実行する場合に使用します。
メタテーブルの読み取り 次のメタテーブルのコンテンツに対するクエリは無料です。
__PARTITIONS_SUMMARY__ - パーティション分割テーブルまたは取り込み時間パーティション分割テーブルのパーティションに関するメタデータを取得する場合に使用します。 __TABLES_SUMMARY__ - データセットのテーブルとビューのメタデータを取得する場合に使用します。
UDF の作成、置換、呼び出し 現時点では、永続的なユーザー定義関数(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 分析の無料枠が適用されません。

クエリの料金

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

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

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

デフォルトでは、オンデマンド料金モデルに沿って請求されます。ニーズに合った料金モデルを選択可能で、プロジェクトごとやロケーションごとに 2 つの料金モデルを混在させることもできます。

オンデマンド料金

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

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

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

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

オンデマンド クエリの料金管理

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

Cloud Storage データのクエリ

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

Cloud Storage での列型のクエリ

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

Cloud Storage で外部でパーティションに区分されたデータの料金

Cloud Storage に保存されている Hive パーティション分割テーブルのクエリを実行するには、追加料金がかかります。

BigQuery はプルーニングされていないファイル名の長さの総計をバイト単位で算出します。Hive パーティション分割の料金の総額は最も近い MB の値に四捨五入されます。クエリに含まれる Hive パーティション分割テーブルあたりのデータ処理容量は最低 10 MB です。

定額料金

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

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

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

定額料金:

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

月定額契約

定額料金プランには、BigQuery スロットで測定されるスロット コミットメントを購入して加入します。スロット コミットメントの最小単位は 500 スロットです。コミットメントが期限切れになるまで秒単位で課金されます。次の表に、月間スロット コミットメントのコストを記載します。

年定額契約

定額料金プランには、BigQuery スロットで測定されるスロット コミットメントを購入して加入します。スロット コミットメントの最小単位は 500 スロットです。次の表に、年間スロット コミットメントのコストを記載します。年間コミットメントに加入する場合は、コミットメントが期限切れになるまで秒単位で課金されます。

ストレージの料金

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

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

アクティブ ストレージ

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

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

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

長期保存

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

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

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

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

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

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

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

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

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

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 は 230 バイトで、ギビバイト(GiB)ともいいます。同様に、1 TB は 240 バイト(1,024 GB)です。

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

データの種類 サイズ
INT64/INTEGER 8 バイト
FLOAT64/FLOAT 8 バイト
NUMERIC 16 バイト
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 バイトとして計算されます。

繰り返し列は配列として格納され、サイズは値の個数に基づいて計算されます。たとえば、繰り返しのある(ARRAY<INT64>)、4 個のエントリを含む整数列(INT64)は、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 チームは、スクリプトでスキャンされる総バイト数と、スクリプト内で使用されるステートメントをより明示的に提供します。こちらはベータ版リリースです。料金の更新については 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

table1INTEGER 型の col1STRING 型の col2 の 2 つの列があります。

UPDATE table1 SET col1 = 1 WHERE col2 = 2;

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

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

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

table1INTEGER 型の col1STRING 型の col2 の 2 つの列があります。table2INTEGER 型の 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

mytable2INTEGER 型の idTIMESTAMP 型の ts の 2 つの列があります。mytableINTEGER 型の field1STRING 型の field2 の 2 つの列があります。

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

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

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

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

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

mytable2INTEGER 型の idTIMESTAMP 型の ts の 2 つの列があります。mycolumntable には、INTEGER 型の field1STRING 型の field2BOOLEAN 型の field3TIMESTAMP 型の ts の 4 つの列があります。

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

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

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

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

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

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

mytable2INTEGER 型の idTIMESTAMP 型の ts の 2 つの列があります。mytableINTEGER 型の field1STRING 型の 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: 単一パーティションの更新

mytable2INTEGER 型の idTIMESTAMP 型の ts の 2 つの列があります。mycolumntable には、INTEGER 型の field1STRING 型の field2BOOLEAN 型の field3TIMESTAMP 型の 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

mytable2INTEGER 型の idTIMESTAMP 型の ts の 2 つの列があります。mytableINTEGER 型の field1STRING 型の 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

mytable2INTEGER 型の idTIMESTAMP 型の ts の 2 つの列があります。mycolumntable には、INTEGER 型の field1STRING 型の field2BOOLEAN 型の field3TIMESTAMP 型の 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 の timestampcustomer_idtotalSale 列をスキャンします。
  • 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;
このページは役立ちましたか?評価をお願いいたします。

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

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