データストレージに関する考慮事項¶

アカウント用のストレージ（アカウント管理者のみ）¶

ACCOUNTADMIN ロールが割り当てられている場合（つまり、Snowflakeアカウントの最上位の管理者として機能している場合）は、 Snowsight または Classic Console を使用して、アカウント全体のデータストレージを表示できます。

Snowsight:

Select Admin » Cost Management » Consumption。

Classic Console:

Account » Billing & Usage » Average Storage Used をクリックします

このページには、アカウントの合計平均データストレージと、すべてのデータベース、内部ステージと名前付きステージ、Fail-safeのデータの合計が表示されます。

詳細については、 ストレージコストの調査 をご参照ください。

個別のテーブルストレージ¶

適切な権限を持つユーザーは、個々のテーブルのデータストレージを表示できます。Snowflakeは、テーブルデータストレージを表示するために次の方法を提供します。

Classic Console:

Databases » <データベース名> » Tables をクリックします

SQL:

SHOW TABLES コマンドを実行します。

または

次のいずれかをクエリします。

• TABLE_STORAGE_METRICS ビュー（Snowflake Information Schema 内）。

• TABLE_STORAGE_METRICS ビュー ビュー（ Account Usage 内）。

3つの方法のうち、 TABLE_STORAGE_METRICS が最も詳細な情報を提供するのは、CDPライフサイクルの次の3つの状態のテーブルデータの物理ストレージの内訳（バイト単位）が含まれているためです。

• Active（ACTIVE_BYTES 列）

• Time Travel（TIME_TRAVEL_BYTES 列）

• Fail-safe（FAILSAFE_BYTES 列）

ビューには、所有ストレージと、テーブルのクローンを作成するときに発生する参照ストレージを区別するための列もあります（以下のセクションを参照）。

ステージングされたファイルのストレージ（データロード用）¶

テーブルへのデータの一括ロードをサポートするために、Snowflakeはロードするデータを含むファイルが保存されるステージを利用します。Snowflakeは、内部ステージと外部ステージの両方をサポートしています。

Snowflakeの内部ステージでステージングされるデータファイルには、Time TravelおよびFail-safeに関連する追加コストはかかりませんが、標準のデータストレージコストが発生します。そのため、ストレージコストの管理に役立つように、Snowflakeは、これらのファイルを監視し、データがロードされてファイルが不要になったらステージから削除することをお勧めします。これらのファイルは、データのロード中（ COPY INTO <テーブル> コマンドを使用）またはその後（ REMOVE コマンドを使用）で削除することを選択できます。

詳細については、 データロードに関する考慮事項 をご参照ください。

テーブル IDs¶

すべてのSnowflakeテーブルには、テーブルを一意に識別する ID があります。さらに、すべてのテーブルは CLONE_GROUP_IDにも関連付けられています。テーブルにクローンがない場合、 ID と CLONE_GROUP_ID は同一です。これらの IDs は TABLE_STORAGE_METRICS ビューに表示されます。

所有ストレージと参照ストレージ¶

テーブルのクローンが作成されると、元のテーブルの新しい ID と CLONE_GROUP_ID が割り当てられます。クローンが作成されると、両方のテーブルのすべてのマイクロパーティションが完全に共有されます。これらのマイクロパーティションに関連付けられたストレージは、クローングループ内の最も古いテーブルによって 所有 され、クローンはこれらのマイクロパーティションを 参照 します。

クローンが作成された後、クローングループ内の両方のテーブルには個別のライフサイクルがあり、いずれかのテーブルに対する DML 操作は、それぞれのテーブルが所有する新しいマイクロパーティションを作成します。これらのマイクロパーティションに関連付けられたストレージは、 TABLE_STORAGE_METRICS ビューの RETAINED_FOR_CLONE_BYTES 列を使用してクエリできます。

クローングループ内のすべてのテーブルには独立したライフサイクルがあるため、これらのテーブル内にあるストレージの所有権をクローングループ内の別のテーブルに譲渡する必要がある場合があります。例えば、次で構成されるクローングループを考えます：

元のテーブル：		クローン先：		クローン先：
T1	»	T2	»	T3

T2とT3がいくつかのマイクロパーティションを共有し、T2が削除された場合、T2がFail-safeになる前にそのストレージの所有権を譲渡する必要があります。Snowflakeでは、この転送はマイクロパーティションがTime Travel状態を終了するときに発生し、そうでない場合はFail-safeになります。上記の場合、以前にT2が所有していたマイクロパーティションは、Time Travelの保持期間が終了するとT3に転送されます。

仮テーブル¶

他の SQL データベースと同様に、仮テーブルは単一のユーザーセッション内およびセッションの期間内にのみ存在します。Snowflake仮テーブルにはFail-safeがなく、Time Travelの保持期間は0または1日のみです。ただし、テーブルが削除されるとTime Travel期間が終了します。

したがって、仮テーブルで発生する CDP 料金の最大合計は1日です（または、テーブルが明示的に削除された場合、またはセッションの終了の結果として削除された場合はそれより少なくなります）。この期間中、テーブルでTime Travelを実行できます。

一時テーブル¶

一時テーブルはSnowflakeに固有のものです。これらには、永続テーブルと仮テーブルの両方の特性があります：

• 仮テーブルとは対照的に、一時テーブルはセッションに関連付けられていません。それらは、そのテーブルにアクセスする権限を持つすべてのユーザーに表示されます。また、永続テーブルと同様に、作成されたセッションを超えて保持されます。

• 仮テーブルには、一時テーブルにはFail-safe機能がなく、Time Travelの保持期間は0または1日のみです。

したがって、一時テーブルで発生した CDP 料金の最大合計は1日です。この期間中、テーブルでTime Travelを実行できます。