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

このトピックでは、特にテーブルの継続的なデータ保護(CDP)に関連するデータストレージコストを制御するためのガイドラインとベストプラクティスを提供します。

CDPは、Time TravelとFail-safeを含み、追加費用なしですべてのSnowflakeアカウントで利用可能な標準機能セットです。ただし、アカウントに作成されたテーブル、スキーマ、データベースに保存されているすべてのデータに対してアカウントに課金されるため、 CDP は、保存されるデータの合計量とデータの格納期間に基づいて、ストレージコストに影響を与えます。

ストレージは、Active、Time Travel、またはFail-safeの状態に関係なく、データに対して計算され、課金されます。これらのライフサイクル状態は連続的であるため、 CDP で保護された更新/削除されたデータは、データがFail-safe状態を離れるまでストレージコストを負担し続けます。

注釈

INSERT、 COPY、または SNOWPIPE を使用してデータをロードすると、 TIME_TRAVEL_BYTES と FAILSAFE_BYTES に料金が発生します。これは、小さなマイクロパーティションのデフラグが小さなマイクロパーティションを削除し、同じデータを持つ新しいマイクロパーティションを作成するためです。削除されたマイクロパーティションは TIME_TRAVEL_BYTES と FAILSAFE_BYTES に影響します。

このトピックの内容:

データストレージの監視

アカウント用のストレージ(アカウント管理者のみ)

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

Snowsight

Select Admin » Cost Management » Consumption

Classic Console

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

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

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

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

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

Classic Console

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

SQL

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

または

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

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 コマンドを使用)で削除することを選択できます。

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

ちなみに

ステージングされたファイルの定期的なパージには、データロードのパフォーマンスの向上など、他の利点があります。

テーブル、スキーマ、およびデータベースのクローニング

Snowflakeのゼロコピークローニング機能は、テーブル、スキーマ、またはデータベースの「スナップショット」を迅速に取得し、基礎となるストレージを最初に共有するオブジェクトの派生コピーを作成する便利な方法を提供します。これは、追加のコストが発生しない(クローンオブジェクトに変更が加えられるまで)インスタントバックアップを作成する場合に非常に役立ちます。

ただし、各クローンには独自のライフサイクルがあるため、クローンを作成するとストレージの合計使用量の計算がより複雑になります。つまり、元のオブジェクトまたはクローンを互いに独立して変更でき、これらの変更は CDP によって保護されます。

例えば、テーブルのクローンが作成されると、クローンは元のテーブルのすべての既存のマイクロパーティションをクローン作成時に共有するため、データストレージを使用しません。ただし、クローンは元のテーブルとは独立して行を追加、削除、または更新できます。クローンを変更するたびに、クローンによって排他的に所有され、 CDP によって保護される新しいマイクロパーティションが作成されます。

さらに、作成できるクローンの数や反復に制限はなく、クローンをクローンできます(例えば、クローンのクローンのクローンを作成できるなど)。これにより、それぞれが共有および独立したデータストレージの独自の部分を持つ、クローンオブジェクトのnレベルの階層が作成されます。

テーブル 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に転送されます。

存続期間の短いテーブルのコスト管理

CDP はデータを長期的に保護するように設計されています。このデータは通常、永続的なテーブルに保存されます。作成時に特に指定されていない限り、Snowflakeのテーブルは永続的なものとして作成されます。

ETL またはデータモデリングプロセス中に、一時的なテーブルが作成される場合があります。これらのテーブルの場合、 CDP のストレージコストを負担することは意味がありません。Snowflakeは、存続期間の短いテーブルをサポートする2つの独立したメカニズムを提供します:

  • 仮テーブル

  • 一時テーブル

仮テーブル

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

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

重要

接続とセッションは、Snowflake内の異なる概念です。Snowflakeにログインすると、1つ以上のセッションが作成される場合があります。Snowflakeセッションは、ユーザーがセッションを明示的に終了した場合、または4時間後に非アクティブのためセッションがタイムアウトした場合にのみ終了します。Snowflakeから切断しても、アクティブなセッションは終了しません。したがって、Snowflakeセッションは非常に長く存続し、そのセッション内で作成された仮テーブルは、削除されるかセッションが終了するまで存在し続けます。

仮テーブルの予期しないストレージコストを回避するために、Snowflakeは、セッション内で必要に応じて作成し、不要になったら削除することをお勧めします。

一時テーブル

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

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

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

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

大規模でチャーンの大きいテーブルのコスト管理

データプラットフォームでは、テーブルは通常 ファクト または ディメンション のいずれかのテーブルであり、使用パターンが異なるため、ストレージに関する考慮事項も異なります。

  • 通常、ファクトテーブルのサイズは非常に大きく、チャーン(行の更新または削除)の程度は低くなります。ファクトテーブルへのほとんどの変更は、新しいデータの挿入、または場合によっては古いデータの削除です。CDP は非常に低いストレージコストで完全なデータ保護を提供するため、ファクトテーブルに最適です。

  • ディメンションテーブルには、異なる更新パターンがあります。行の更新と削除は、ディメンションテーブルではより一般的です。テーブルの1つ以上の行が更新または削除されると、このデータを格納する基礎となるマイクロパーティションは、 CDP に関連付けられたライフサイクル遷移を開始します。チャーン率の高いディメンションテーブルの場合、Time TravelおよびFail-safeデータに関連付けられた結果のストレージは、アクティブなテーブルストレージよりもはるかに大きくなる可能性があります。

ほとんどのディメンションテーブルでは、これらの更新に関連する CDP ストレージコストは妥当です。ディメンションテーブルは通常サイズが小さく、頻繁に更新される場合でも、Snowflakeのストレージのコストは安価であり、 CDP の利点はコストをはるかに上回ります。

一部の大規模でチャーン率の高いディメンションテーブルの場合、 CDP に関連付けられたストレージコストがかなり高くなる可能性があります。テーブルに対して複数の更新が行われると、影響を受けるすべてのマイクロパーティションが再作成され、CDPストレージライフサイクルを通じて移行します。

チャーン率の高いディメンションテーブルは、 TABLE_STORAGE_METRICS ビューで FAILSAFE_BYTES を ACTIVE_BYTES で割った比率を計算すると識別できます。比率が大きいテーブルは、チャーン率の高いテーブルと見なされます。Snowflakeのストレージは安価であり、チャーン率の高いテーブルのほとんどはストレージの総量を控えめに消費するため、推奨されるオプションはこれらのテーブルを永続として作成し、データを保護するために CDP を使用することです。

場合によっては、チャーン率の高いディメンションテーブルのストレージのコストが高すぎるため、 CDPの代替オプションを選択する場合があります。極端な例として、テーブル内のすべてのマイクロパーティションに関連付けられた行を持つテーブルを考えます(物理ストレージの200 GB で構成されます)。すべての行が1日に20回更新されると、テーブルは次のストレージを消費します:

Active

200 GB

Time Travel

4 TB

Fail-safe

28 TB

合計ストレージ

32.2TB

CDPコストが過度に発生する大規模で解約率の高いディメンションテーブルの場合、解決策は、これらのテーブルを一時的なものとして作成し、Time Travelの保持をゼロ(つまり、DATA_RETENTION_TIME_IN_DAYS=0)にしてから、これらのテーブルを定期的に永続的なテーブルにコピーすることです。これにより、これらのテーブルの完全バックアップが効果的に作成されます。各バックアップは CDP によって保護されているため、新しいバックアップが作成されると、古いバックアップを削除できます。

上記の例を使用すると、1日に1回バックアップされた同じ200GB高チャーンディメンションテーブルに関連付けられたストレージコストは次のようになります。

Active

200 GB

Time Travel

200 GB

Fail-safe

1.4TB

バックアップ

200 GB

合計ストレージ

2 TB

ちなみに

バックアップは、データが失われた場合に完全に回復するために必要な頻度で実行する必要があります。これらのテーブルでは、Snowflakeは少なくとも1日に1回はバックアップを取ることを推奨しています。