はじめに
BigQueryは従量課金が基本のため、クエリ実行する機会があるならば課金の仕組みを知っておいた方が安心して利用できます。
今回はデータの活用者、クエリ実行者の視点で必要な内容を中心に説明します。
データ挿入、変更にかかる費用については割愛します。
課金の種類 （主に2種類）
ストレージ料金
保存しているデータ量について課金される料金です
| 操作 | 料金 | 詳細 |
|---|---|---|
| アクティブ | GBあたり $0.02/月 | 毎月10GBまで無料。過去 90 日間で変更されたデータに対する保存料金。 |
| 長期保存 | GB あたり $0.01/月 | テーブル毎、パーティション毎に編集有無を自動計測。 過去 90 日以上データが編集(追加・削除)されていない場合に適用。 |
クエリを実行する側は特に気にすることはない
そもそもかなり安い。S3のデータ保存料金並に安いのでバイナリでなければとりあえずBigQueryに突っ込んどいていいレベルで安い。
データ操作料金（クエリ）
| プラン | 料金 | 詳細 |
|---|---|---|
| オンデマンド | TB あたり $5 | 最も一般的な利用方法。クエリの実行時に処理されたデータ量に応じて課金される。実行に用いる仮想CPUはプロジェクトごとに2,000スロット割り当てられており、十分高速な処理を期待できる。 |
| 定額利用 | 1時間 $4
月額 $2,000 |
100スロットの料金。100スロット単位で購入可能。
さらに年間契約でディカウント有り。 割り当てるスロットを確保できるのでパフォーマンスは安定する。 アイドル時間も課金されるので注意。 2000スロット以上購入しないとオンデマンド以上のパフォーマンスは出ない。 |
多くの場合はオンデマンドでの利用が一般的です。
TB単位のスキャンが頻繁に発生したり、SLAを確保したい場合は定額利用（フラットレート）を検討しましょう。
オンデマンド利用でのポイントは、課金対象となるのはクエリ実行後の取得レコードのデータ容量ではないこと。
データ処理量に対して課金されます。
オンデマンドでのデータ処理対象とは
クエリ実行時のデータ処理容量に対して課金されます。
データ処理容量の考え方、絞り方についてみていきます。
1.select句に含まれたフィールド のデータは全てデータ処理対象になる
| id | name | value |
|---|---|---|
| 1 | inoue | 10 |
| 2 | kimura | 10 |
| 3 | saito | 10 |
例えば、上記のpersonテーブルがあった時、
select * from person where id=1;
を実行すると課金データ量は赤い文字部分のデータ
| id | name | value | ||||||
|---|---|---|---|---|---|---|---|---|
| 1 | inoue | 10
| 2
|
kimura
|
10
|
3
|
saito
|
10
|
|
ポイント：where句で抽出対象を絞ってもデータ処理対象は減らない
--
同様に
select id, name from person where id=1;
を実行すると課金データ量は赤い文字のデータ
| id | name | value |
|---|---|---|
| 1 | inoue | 10 |
| 2 | kimura | 10 |
| 3 | saito | 10 |
ポイント: select句で絞るとデータ処理対象は減る
--
2.where句の条件判定に用いられるフィールド もデータ処理対象
select value from person where id=1;
を実行すると課金データ量は赤い文字のデータ
| id | name | value | ||||||
|---|---|---|---|---|---|---|---|---|
| 1 | inoue | 10
| 2
|
kimura
|
10
|
3
|
saito
|
10
|
|
ポイント: select句、where句、どちらかでも指定したフィールドは処理対象になる
--
3.limit句では絞れない
select * from person where id=1 limit 1;
を実行すると課金データ量は赤い文字部分のデータ
| id | name | value | ||||||
|---|---|---|---|---|---|---|---|---|
| 1 | inoue | 10
| 2
|
kimura
|
10
|
3
|
saito
|
10
|
|
ポイント:limit句では絞れない
4.日付型のカラムパーティショニングで絞ることができる
日付型のカラムを条件に絞るような
select * from person where modify_date <='2020-01-01'
を実行すると課金データ量は赤い文字のデータ
| id | name | value | modify_date |
|---|---|---|---|
| 1 | inoue | 10 | 2020-01-01 |
| 2 | kimura | 20 | 2020-01-01 |
| 3 | saito | 30 | 2020-01-01 |
| 1 | inoue | 10 | 2020-01-02 |
| 2 | kimura | 20 | 2020-01-02 |
| 3 | saito | 30 | 2020-01-02 |
5.クラスタリングカラムで絞ることができる
テーブル作成時にクラスタリングカラムを定義することができる。
(RDBMSのindexをイメージすると近いかもれしれない)
id列をクラスタリングカラムに指定したテーブルに対し、
select * from person where id <=3
を実行すると課金データ量は赤い文字のデータ
| id | name | value | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | inoue | 10
| 2
|
kimura
|
20
|
3
|
saito
|
30
|
4
|
sato
|
10
|
5
|
takahashi
|
20
|
6
|
mizuno
|
30
|
|
データ操作対象の例外（おまけ）
全体のcountをとるだけだと課金対象外
select count(*) from person;
はデータ処理対象 0kb
パーティション指定列は課金対象外
select distinct(modify_date) from person order by modify_date;
はデータ処理対象 0kb
課金データ処理量の確認方法
コンソールでクエリを入力すると実行前にsyntaxチェックと同時に処理量をpreviewしてくれます。
実行前に確認しておけば安心して実行することができますね。
利用量制限
カスタムコスト管理
プロジェクトレベル、もしくはユーザーレベルで利用量の制限を行うことができます
https://cloud.google.com/bigquery/docs/custom-quotas?hl=ja
カスタムコストが設定しておくと、無茶な使い方したら上限に達して利用を止められます。
うっかり何百万円も利用してしまうというようなことはないので安心して使えますね。
※ カスタムコスト管理設定方法の記事も書きました
https://qiita.com/laha/items/fb9acb5794a14f9c2d89