TABLE_STORAGE_BY_FOLDER ビュー

INFORMATION_SCHEMA.TABLE_STORAGE_BY_FOLDER ビューには、現在のプロジェクトの親フォルダ（サブフォルダを含む）内のテーブルまたはマテリアライズドビューごとに 1 行が表示されます。

このテーブルはリアルタイムデータを保持しておらず、数秒から数分遅れることがあります。パーティションまたはテーブルの有効期限のみに起因するストレージの変更、またはデータセットのタイムトラベル期間への変更に起因するストレージの変更が INFORMATION_SCHEMA.TABLE_STORAGE ビューに反映されるまでに、最大で 1 日かかる場合があります。1,000 を超えるテーブルを含むデータセットが削除された場合、削除されたデータセットのタイムトラベル期間が経過するまで、このビューに変更は反映されません。

テーブルストレージビューでは、現在のストレージの消費を簡単にモニタリングできます。また、ストレージで論理非圧縮バイト、物理圧縮バイト、タイムトラベルバイトのいずれを使用しているかの詳細も確認できます。この情報は、今後の拡張に向けた計画や、テーブルの更新パターンの把握に役立ちます。

`*_BYTES` 列に含まれるデータ

テーブルストレージビューの *_BYTES 列には、ストレージの使用量（バイト）に関する情報が含まれています。この情報は、マテリアライズドビューと次のタイプのテーブルのストレージ使用量を調べることで確認できます。

テーブルの作成と使用で説明されている方法のいずれかを使用して作成された永続テーブル。
セッションで作成された一時テーブル。これらのテーブルは、生成された名前（「_c018003e063d09570001ef33ae401fad6ab92a6a」など）でデータセットに配置されます。
複数ステートメントクエリ（「スクリプト」）で作成された一時テーブル。これらのテーブルは、生成された名前（「_script72280c173c88442c3a7200183a50eeeaa4073719」など）でデータセットに配置されます。

クエリ結果キャッシュに保存されているデータは課金されないため、*_BYTES 列の値には含まれません。

クローンとスナップショットは、ベーステーブルが使用しているストレージとの差分を表示するのではなく、あたかも完全なテーブルであるかのように *_BYTES 列の値を表示するため、過大評価になります。請求では、ストレージ使用量のこの差分が正しく反映されます。クローンとスナップショットの作成によって保存され、課金される差分バイトについて詳しくは、TABLE_STORAGE_USAGE_TIMELINE ビューをご覧ください。

ストレージ課金を予測する

データセットの毎月のストレージ請求額を予測するには、データセットによって使用されるデータセットストレージ課金モデルに応じて、このビュー内の logical 列または physical *_BYTES 列を使用できます。これはおおよその予測であり、正確な請求額は、BigQuery のストレージ課金インフラストラクチャによる使用量に基づいて計算され、Cloud Billing に表示されることに注意してください。

論理課金モデルを使用するデータセットの場合、月間ストレージ費用は、次のように予測できます。

((ACTIVE_LOGICAL_BYTES 値 / POW(1024, 3)) * アクティブな論理バイトの料金) + ((LONG_TERM_LOGICAL_BYTES 値 / POW(1024, 3)) * 長期論理バイトの料金)

テーブルの ACTIVE_LOGICAL_BYTES 値には、そのテーブルで現在使用されているアクティブなバイト数が反映されます。

物理課金モデルを使用するデータセットの場合は、ストレージ費用を次のように予測できます。

((ACTIVE_PHYSICAL_BYTES + FAIL_SAFE_PHYSICAL_BYTES 値 / POW(1024, 3)) * アクティブな物理バイトの料金) + ((LONG_TERM_PHYSICAL_BYTES 値 / POW(1024, 3)) * 長期物理バイトの料金)

テーブルの ACTIVE_PHYSICAL_BYTES 値には、そのテーブルで現在使用されているアクティブなバイト数と、そのテーブルのタイムトラベルに使用されたバイト数が反映されます。

テーブルのアクティブなバイト数のみを表示するには、ACTIVE_PHYSICAL_BYTES 値から TIME_TRAVEL_PHYSICAL_BYTES 値を減算します。

詳細については、ストレージの料金をご覧ください。

必要な権限

INFORMATION_SCHEMA.TABLE_STORAGE_BY_FOLDER ビューをクエリするには、プロジェクトの親フォルダに対する次の Identity and Access Management（IAM）権限が必要です。

bigquery.tables.get
bigquery.tables.list

次の各 IAM 事前定義ロールには、上の権限が含まれています。

roles/bigquery.admin
roles/bigquery.dataViewer
roles/bigquery.dataEditor
roles/bigquery.metadataViewer

BigQuery の権限の詳細については、BigQuery の IAM ロールと権限をご覧ください。

スキーマ

INFORMATION_SCHEMA.TABLE_STORAGE_BY_FOLDER ビューのスキーマは次のとおりです。

列名	データ型	値
`folder_numbers`	`REPEATED INTEGER`	プロジェクトを含むフォルダの番号 ID。プロジェクトを直接含むフォルダから始まり、子フォルダを含むフォルダというように続きます。たとえば、`folder_numbers` が `[1, 2, 3]` の場合、フォルダ `1` にはプロジェクトが直接含まれ、フォルダ `2` には `1` が含まれ、フォルダ `3` には `2` が含まれます。この列は、`TABLE_STORAGE_BY_FOLDER` にのみ入力されます。
`project_id`	`STRING`	データセットを含むプロジェクトのプロジェクト ID。
`project_number`	`INT64`	データセットを含むプロジェクトのプロジェクト番号
`table_catalog`	`STRING`	データセットを含むプロジェクトのプロジェクト ID。
`table_schema`	`STRING`	テーブルやマテリアライズドビューを含むデータセットの名前（`datasetId` とも呼ばれる）
`table_name`	`STRING`	テーブルまたはマテリアライズドビューの名前（`tableId` とも呼ばれる）
`creation_time`	`TIMESTAMP`	テーブルの作成時刻。
`total_rows`	`INT64`	テーブルまたはマテリアライズドビューの行の総数
`total_partitions`	`INT64`	テーブルまたはマテリアライズドビューに存在するパーティションの数。パーティション分割されていないテーブルは 0 を返します。
`total_logical_bytes`	`INT64`	テーブルまたはマテリアライズドビューの論理（非圧縮）バイトの合計数
`active_logical_bytes`	`INT64`	作成後 90 日未満の論理（非圧縮）バイト数。
`long_term_logical_bytes`	`INT64`	作成後 90 日以上経過した論理（非圧縮）バイト数。
`current_physical_bytes`	`INT64`	テーブルの現在のストレージを表す、すべてのパーティションにわたる物理バイトの合計数。
`total_physical_bytes`	`INT64`	ストレージに使用されている物理（圧縮）バイトの合計数。これには、アクティブデータ、長期保存データ、タイムトラベルデータ（削除または変更されたデータ）のバイト数が含まれます。フェイルセーフ（タイムトラベル期間後も保持される、削除または変更されたデータ）のバイト数は含まれません。
`active_physical_bytes`	`INT64`	90 日未満の物理（圧縮）バイト数。これには、タイムトラベル（削除または変更されたデータ）のバイト数が含まれます。
`long_term_physical_bytes`	`INT64`	作成後 90 日以上経過した物理（圧縮）バイト数
`time_travel_physical_bytes`	`INT64`	タイムトラベルストレージ（削除または変更されたデータ）で使用される物理（圧縮）バイト数
`storage_last_modified_time`	`TIMESTAMP`	データがテーブルに最後に書き込まれた時刻。データが存在しない場合は `NULL` を返します。
`deleted`	`BOOLEAN`	テーブルが削除されているかどうかを示します。
`table_type`	`STRING`	テーブルのタイプ。例: `BASE TABLE`
`managed_table_type`	`STRING`	この列はプレビュー版です。テーブルのマネージドタイプ。例: `NATIVE`、`BIGLAKE`
`fail_safe_physical_bytes`	`INT64`	フェイルセーフストレージで使用される物理（圧縮）バイト数（削除または変更されたデータ）。
`last_metadata_index_refresh_time`	`TIMESTAMP`	テーブルのメタデータインデックスの最終更新時間。
`table_deletion_reason`	`STRING`	`deleted` フィールドが true の場合のテーブル削除の理由。値は次のいずれかになります。 `TABLE_EXPIRATION:` 設定された有効期限が切れた後にテーブルが削除されました `DATASET_DELETION:` データセットがユーザーによって削除されました `USER_DELETED:` テーブルがユーザーによって削除されました
`table_deletion_time`	`TIMESTAMP`	テーブルの削除時刻。

安定性を確保するため、情報スキーマクエリではワイルドカード（SELECT *）を使用するのではなく、列を明示的にリストすることをおすすめします。列を明示的にリストすると、基になるスキーマが変更されてもクエリは中断されません。

スコープと構文

このビューに対するクエリでは、リージョン修飾子を指定する必要があります。次の表に、このビューのリージョンスコープを示します。

ビュー名	リソーススコープ	リージョンスコープ
[`PROJECT_ID`.]`region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_FOLDER	指定したプロジェクトを含むフォルダ	`REGION`

次のように置き換えます。

省略可: PROJECT_ID: Google Cloud プロジェクトの ID。指定しない場合は、デフォルトのプロジェクトが使用されます。
REGION: 任意のデータセットリージョン名。例: `region-us`

注: INFORMATION_SCHEMA ビューに対してクエリを実行するには、リージョン修飾子を使用する必要があります。クエリ実行のロケーションは、INFORMATION_SCHEMA ビューのリージョンと一致する必要があります。

指定されたプロジェクトの親フォルダにあるテーブルのストレージ情報を取得するには、次のクエリを実行します。

SELECT * FROM `myProject`.`region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_FOLDER;

例

次のクエリは、フォルダ内のどのプロジェクトが最もストレージを使用しているかを示します。

SELECT
  project_id,
  SUM(total_logical_bytes) AS total_logical_bytes
FROM
  `region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_FOLDER
GROUP BY
  project_id
ORDER BY
  total_logical_bytes DESC;

次のような結果になります。

+---------------------+---------------------+
|     project_id      | total_logical_bytes |
+---------------------+---------------------+
| projecta            |     971329178274633 |
+---------------------+---------------------+
| projectb            |     834638211024843 |
+---------------------+---------------------+
| projectc            |     562910385625126 |
+---------------------+---------------------+