G-genの杉村です。Google Cloud（旧称 GCP）のフルマネージドなデータウェアハウスサービスである BigQuery の、ストレージ料金体系について解説します。

BigQuery の課金体系
2つの課金モデル
- 論理ストレージ（Logical Storage）課金
- 物理ストレージ（Physical storage）課金
アクティブと長期
ユースケース
制約
- 物理ストレージ課金モデルの利用可否
- ストレージ課金モデルの変更のインターバル期間

BigQuery の課金体系

前提知識として、BigQuery の利用料金は以下の2つの合計であることを理解する必要があります。

ストレージ料金（格納したデータサイズに応じた課金）
コンピュート料金（コンピュート処理リソースに対する課金）

当記事では、このうち 1. のストレージ料金について解説します。

参考 : ストレージの課金モデル

BigQuery のコンピュート料金体系の1つである BigQuery Editions については、以下の記事を参照してください。

blog.g-gen.co.jp

2つの課金モデル

論理ストレージ（Logical Storage）課金

論理ストレージ課金モデルは、テーブルに格納されたデータの、圧縮前の額面データサイズに対して課金するモデルです。

デフォルトでは、BigQuery データセットのストレージ課金モデルは論理ストレージ（Logical Storage）に設定されています。

BigQuery では、データは透過的に圧縮されて格納されています。例えば100 MB のデータを格納したとしても、実際にはデータは圧縮されており、実際に Google のストレージを占有しているデータサイズはもっと小さいものになります。論理ストレージ課金では、実際に占有されているデータサイズではなく、額面データサイズ（先の例では 100 MB）に対して課金するモデルです。

物理ストレージ（Physical storage）課金

一方の物理ストレージ（Physical Storage）課金モデルは、圧縮後のデータサイズに対して計算が行われる課金モデルです。なお物理ストレージ課金モデルは、2023年7月に一般公開された新しいモデルです。

当然、データサイズは論理ストレージ課金モデルより小さく計算されますが、課金単価は論理ストレージよりも高いものが使われます。後述しますが、多くの場合でこちらの課金モデルのほうが、結果的に安価になる傾向があります。

重要な点として、物理ストレージ課金モデルを選択したか否かに関わらず、BigQuery のデータは透過的に圧縮されています。論理ストレージ課金か物理ストレージ課金かの選択は、あくまで課金の計算方法の選択肢であり、この選択により圧縮の有無が変わったり、パフォーマンスが変わるものではありません。

BigQuery の圧縮の内部的な仕組みについては、以下もご参照ください。

参考 : Experimenting with BigQuery data compression

アクティブと長期

論理、物理のいずれの課金モデルを選択した場合でも、BigQuery のストレージには、アクティブストレージと長期ストレージがあります。

アクティブストレージ（Active storage）は、過去90日間以内にテーブルに挿入されたり、更新があったデータが格納される領域です。

長期ストレージ（Long-term storage）は、過去90日間の間、変更がないデータが格納される領域です。データの挿入または格納後、90日間放置すると、データは自動的に長期ストレージに移行します。

長期ストレージの課金単価は、アクティブストレージの半分です。BigQuery テーブルにデータを一度挿入したあとは、触れずに放置しておくことで、自動的に安価になります。

参考 : Storage pricing

ユースケース

どちらのモデルを選択すべきか

BigQuery では、データセットごとに論理ストレージ課金モデルを適用するか物理ストレージ課金モデルを適用するかを選択できます。デフォルトでは、論理ストレージ課金モデルが適用されています。

以下は、2024年9月現在の US ロケーションの料金単価です。

課金モデル	単価
論理ストレージ（アクティブ）	$0.02 / GiB / 月
論理ストレージ（長期）	$0.01 / GiB / 月
物理ストレージ（アクティブ）	$0.04 / GiB / 月
物理ストレージ（長期）	$0.02 / GiB / 月

物理ストレージ課金モデルは、論理ストレージ課金モデルの単価よりも2倍高いことがわかります。つまり、データの圧縮率が50%を超えていれば、物理ストレージ課金を選択したほうが安くなります。

最新の料金は、以下のドキュメントを参照してください。

参考 : Storage pricing

圧縮率の例

あくまで一般的な傾向ですが、BigQuery では圧縮によりデータは4分の1〜12分の1程度、あるいはそれ以上の圧縮率になる可能性があります。

データ圧縮率の例をいくつか紹介します。

以下は、G-gen Tech Blog で収集している Google Analytics 4 のデータを BigQuery にエクスポートしたテーブルの情報です。ある日のテーブルは、論理バイト数は 11.69 MB ですが、物理バイト数は 638.69 KB であり、約 18 分の 1 になっています。

もう一つの例です。以下はパブリックデータセットの bigquery-public-data.baseball.games_wide テーブルの情報です。この例では 1.76 GB が 32.22 MB まで圧縮されており、約 56 分の 1 になっています。

データの圧縮率はデータの性質によって異なるため一概には言えませんが、多くのケースで物理ストレージ課金モデルを選択することで安価になると考えられます。

圧縮率の確認（コンソール）

データの実際の圧縮状況は、テーブルの詳細情報から確認できます。BigQuery の Web コンソールから、テーブルの詳細画面を開くと、論理バイト数と物理バイト数が確認できます。

以下の例だと、1.6%ほどにまでデータが圧縮されていますので、物理ストレージ課金を選択したほうが、安価になることがわかります。

圧縮率の確認（システムビュー）

また、BigQuery のシステムビューである INFORMATION_SCHEMA にクエリすることで、Google Cloud 組織全体から情報を取得することも可能です。

以下のサンプルクエリでは INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION から情報を取得しています。

参考 : TABLE_STORAGE_BY_ORGANIZATION view

このクエリにより、Google Cloud 組織全体で、プロジェクトごとの論理ストレージ（アクティブ）、論理ストレージ（長期）、物理ストレージ（アクティブ）、物理ストレージ（長期）それぞれのバイト数、また費用見積もりを確認することができます。クエリの内容は、環境にあわせて書き換えてください。

DECLARE active_logical_pricing, longterm_logical_pricing, active_physical_pricing, longterm_physical_pricing NUMERIC;
SET active_logical_pricing    = 0.023;
SET longterm_logical_pricing  = 0.016;
SET active_physical_pricing   = 0.052;
SET longterm_physical_pricing = 0.026;
-- 上記は2024/09時点の東京リージョン価格。適宜変更してください
  
SELECT
  project_id,
  ROUND(SUM(total_logical_bytes/POW(1024, 3)), 2) AS total_logical_gigabytes,
  ROUND(SUM(
    (
      active_logical_bytes/POW(1024, 3)
    ) * active_logical_pricing
    +
    (
      long_term_logical_bytes/POW(1024, 3)
    ) * longterm_logical_pricing
  ), 2) AS total_logical_price,
  ROUND(SUM(total_physical_bytes/POW(1024, 3)), 2) AS total_physical_gigabytes,
  ROUND(SUM(fail_safe_physical_bytes/POW(1024, 3)), 2) AS fail_safe_physical_gigabytes,
  ROUND(SUM(
    (
      (active_physical_bytes/POW(1024, 3)) + (fail_safe_physical_bytes/POW(1024, 3))
    ) * active_physical_pricing
    +
    (
      long_term_physical_bytes/POW(1024, 3)
    ) * longterm_physical_pricing
  ), 2) AS total_physical_price,
  ROUND(SAFE_DIVIDE(SUM(total_logical_bytes), SUM(total_physical_bytes)), 2) AS compression_ratio
FROM
  `region-asia-northeast1.INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION`
  -- 上記はデータセットのリージョンに合わせて適宜変更してください
GROUP BY
  1

注意点として INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION をクエリするには、実行アカウントは組織レベルで bigquery.tables.get および bigquery.tables.list の権限を持っている必要があります。この権限を得るには、クエリするアカウントに対して組織レベルで BigQuery データ閲覧者 (roles/bigquery.dataViewer) ロールや BigQuery 管理者 (roles/bigquery.admin) を付与します。組織レベルで オーナー (roles/owner) を付与されていても、オーナーには bigquery.tables.get が含まれていないため権限不足ですのでご注意ください。

組織レベルでの情報取得が不要であり、プロジェクトレベルの情報で十分な場合は、FROM 句で取得元システムビューを region-${リージョン名}.INFORMATION_SCHEMA.TABLE_STORAGE とすることで、プロジェクト単位の情報取得が可能です。こちらであれば、IAM 権限もプロジェクトレベルで十分です。

BigQuery の IAM 権限の詳細についてさらに知りたい場合は、以下をご参照ください。

blog.g-gen.co.jp

タイムトラベル・フェイルセーフへの課金

BigQuery にはタイムトラベル機能とフェイルセーフ機能があり、データを削除したり変更したりしても、デフォルトで過去14日間（タイムトラベルで7日間、フェイルセーフでさらに7日間）のデータが保持されます。

参考 : タイムトラベルとフェイルセーフによるデータの保持

物理ストレージ課金モデルを選択すると、このタイムトラベルとフェイルセーフのデータサイズにも課金が発生します。その一方で、論理ストレージ課金モデルでは課金されません。課金は、アクティブストレージの単価で行われます。

ストレージ料金を節約するために、タイムトラベルの保存期間をデフォルトの7日間から変更することも可能です。フェイルセーフの保存期間（タイムトラベル期間の後、追加で7日間）は変更できません。

この仕様から、データの削除や更新が頻繁なテーブルでは、物理ストレージ課金にすると料金が高くなるおそれがあります。デフォルト設定では、例えば定期的にデータを洗い替え（一度 TRUNCATE してから INSERT）しているようなテーブルだと、タイムトラベル領域とフェイルセーフ領域に削除されたデータが14日間、積み上がり続け、課金対象とされることになります。

また、BigQuery Data Transfer Serviceのデータセットコピー機能で Overwrite destination table オプションを使う場合も、この仕様に注意が必要です。以下の記事も参照してください。