ストレージコストについて¶

ストレージコストは、次のコストを表します。

バルクデータのロード/アンロード用にステージングされたファイル（圧縮または非圧縮で保存）。
Time Travel の履歴データを含むデータベーステーブル。
データベーステーブルの Fail-safe。
クローンを所有するテーブルで削除されたデータを参照する、データベーステーブルのクローン。

Snowflakeにデータを保存するための月額費用は、テラバイト（TB）あたりの定額に基づいています。請求される金額は、アカウントのタイプ（容量またはオンデマンド）とリージョン（US または EU）によって異なります。

ストレージの価格については、 Snowflakeの価格ガイドをご参照ください。

このトピックの内容:

ステージングされたファイルのコスト¶

一括データのロード/アンロード用にステージングされたファイルには、ファイルのサイズに基づいてストレージコストが発生します。データのロードの詳細については、 Snowflakeにデータをロードするをご参照ください。

データベースのコスト¶

データベースのコストには、データベーステーブルに格納されたデータが含まれます。データベースのコストには、Time Travel用に維持された履歴データも含まれます。Snowflakeはテーブルに保存されているすべてのデータを自動的に圧縮し、圧縮されたファイルサイズを使用して、アカウントに使用される合計ストレージを計算します。

データストレージに関する考慮事項もご参照ください。

Time TravelおよびFail-safeのコスト¶

Time TravelとFail-safeの料金は、データが変更された時点から24時間（つまり、1日）ごとに計算されます。履歴データが保持される日数は、テーブルタイプとテーブルのTime Travel保持期間に基づきます。

Snowflakeは、更新または削除された個々のテーブル行の復元に必要な情報のみを維持することにより、履歴データに必要なストレージの量を最小限に抑えます。その結果、ストレージ使用量は、変更されたテーブルの割合として計算されます。テーブルの完全なコピーは、テーブルがドロップまたは切り詰められた場合にのみ維持されます。

Time TravelおよびFail-safeのストレージコストもご参照ください。

仮テーブルと一時テーブルのコスト¶

Time TravelとFail-safeに関連するストレージコストの管理を支援するために、Snowflakeでは仮テーブルと一時テーブルの2つのテーブル型を提供します。仮テーブルと一時テーブルには、永続テーブルと同様の料金は発生しません。

一時テーブルと仮テーブルは明示的に削除されるまで、Snowflakeがアカウントに請求するストレージ料金に加算されます。これらのテーブル型に保存されたデータは、存在する間、Snowflakeがアカウントに請求する全体的なストレージ料金に加算されます。
仮テーブルは通常、 ETL やその他のセッション固有のデータなど、非永続的なセッション固有の一時的なデータに使用されます。仮テーブルは、有効期間または関連するセッションの間にのみ存在します。セッションが終了すると、仮テーブルのデータはパージされ、回復できなくなります。仮テーブルは、それらを作成した特定のセッション以外ではアクセスできません。
一時テーブルは、明示的に削除されるまで存在し、適切な権限を持つすべてのユーザーによって使用できます。
一時テーブルと仮テーブルには、0日または1日のTime Travel保持期間を設定できます。
一時テーブルと仮テーブルには、Fail-safe期間はありません。
一時テーブルと仮テーブルには、最大で1日分のストレージコストが発生する可能性があります。

次のテーブルは、テーブルタイプに基づいたさまざまなシナリオを示しています。

テーブルタイプ	Time Travel保持期間（日数）	Fail-safe期間（日数）	維持される最小、最大履歴データ（日数）
永続	0 または1（Snowflake Standard Editionの場合）	7	7 , 8
永続	0 から 90（Snowflake Enterprise Editionの場合）	7	7 , 97
一時的	0または1	0	0 , 1
仮	0または1	0	0 , 1

仮テーブルと一時テーブルの使用によるストレージコストの管理¶

データを永続テーブル、一時テーブル、または遷移テーブルのいずれに保存するかを選択するときは、次の点を考慮します。

一時テーブルは、作成されたセッションが終了するとドロップされます。一時テーブルに保存されたデータは、テーブルがドロップされた後は回復できません。
遷移テーブルの履歴データは、Time Travel保持期間が終了した後、Snowflakeでは回復できません。Snowflakeから独立してリプリケートまたは再現できるデータには、遷移テーブルのみを使用します。
ファクトテーブルなどの長期間有効なテーブルでは、Fail-safeによって完全に保護されるよう、常に永続として定義する必要があります。
ETL 作業テーブルなどの短期間有効なテーブル（つまり、1日未満）は、Fail-safeのコストを排除するために遷移的なものとして定義できます。
ダウンタイムと失われたデータを再ロードするのに必要な時間が要因である場合、永続テーブルは、Fail-safeコストが追加されても、遷移的なテーブルよりも優れた全体的なソリューションを提供します。

注釈

テーブルのデフォルトのタイプは永続です。テーブルを仮または一時として定義するには、テーブルの作成中にタイプを明示的に指定する必要があります。

ハイブリッドテーブルのコスト¶

運用と分析のワークロードにハイブリッドテーブルを使用する場合、そのテーブルタイプのデータストレージにかかるコストは次の消費率に基づくことを考慮してください。

ハイブリッドテーブルストレージ（主にハイブリッドテーブル自身とその中に含まれるインデックスによって発生）
ハイブリッドテーブルリクエスト

一般的に、ハイブリッドテーブルは標準的なSnowflakeテーブルよりもコストが高くなります。

詳細については、ハイブリッドテーブルのコストについてをご参照ください。

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

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

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

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

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

クロスクラウド自動複製のコスト¶

クロスクラウド自動複製により、手動でデータを複製することなく、他のクラウドリージョンのコンシューマーにデータ製品を提供することができます。データ製品を他のリージョンに自動複製する場合は、ストレージなどのコストが発生します。詳細については、クロスクラウド自動複製のコストの管理をご参照ください。

次のトピック

ストレージコストの調査