ストレージのライフサイクルポリシー¶
ストレージライフサイクルポリシー は、標準およびインタラクティブなSnowflakeテーブルのデータライフサイクルを自動的に管理するスキーマレベルのオブジェクトです。これらのポリシーを使用して、データの年齢やその他の基準など、定義した条件に基づいて、特定のテーブル行をアーカイブまたは期限切れにします。Snowflakeは、共有コンピューティングリソースを使用して、これらのポリシーを毎日自動的に実行します。
ストレージライフサイクルポリシーの仕組み¶
ストレージライフサイクルポリシーを開始するには、次のステップを実行します。
ポリシーを作成する アーカイブまたは期限切れにする行を識別する式を使用します。
テーブルにストレージライフサイクルポリシーをアタッチすると、Snowflakeは約24時間待ってからポリシーを初めて実行します。この最初の遅延の後、Snowflakeは共有コンピューティングリソースを使用して、定義された条件を満たす行を識別して処理することにより、ポリシーを毎日自動的に実行します。
ポリシーが実行されると、式に対して各行をチェックし、データを COOL または COLD ストレージ にアーカイブしするか、期限切れにします(完全に削除)有効期限が発生する前に、 CREATETABLE... FROMARCHIVEOF コマンドを使用してアーカイブデータを取得できます。Snowflakeは、指定されたアーカイブ期間が経過するまで待機し、その後アーカイブストレージからデータを期限切れにします。
主な機能¶
ストレージのライフサイクルポリシーは、Snowflakeデータを管理するために次の利点を提供します。
- ストレージコストの削減
ストレージライフサイクルポリシーは、古いデータをより費用対効果の高い アーカイブティア に自動的に移動することで、コストの最適化を支援します。長期間保持する必要があるが、アクセス頻度が低いデータの場合、アーカイブストレージにより、標準ストレージティアと比較してストレージコストを大幅に削減できます。
- 規制コンプライアンス
規制基準に従ってデータをアーカイブまたは期限切れにするポリシーを構成することで、コンプライアンス要件を自動的に満たします。有効期限が切れる前の特定の時間のデータをアーカイブすることも、アーカイブせずに直接期限切れにすることもできます。これにより、データ管理は組織のガバナンス基準に従って行われます。
- 簡単なデータ管理
ストレージライフサイクルポリシーは、アーカイブルールと有効期限ルールを自動的に実行することで、手作業によるデータ管理タスクを排除します。詳細については、 Monitor storage lifecycle policies をご参照ください。
- 柔軟なデータ取得
必要な行のみを含む新しいテーブルを作成することで、正確に アーカイブデータを取得する ことが可能です。WHERE 句の簡単なコマンドを使用して、復元するアーカイブデータを正確に指定します。
アーカイブストレージティア¶
Snowflakeは、次のストレージティアでデータのアーカイブをサポートしています。
アーカイブティア |
説明 |
|---|---|
COOL |
高速な取得時間を提供するため、データをすぐに利用できます。最小アーカイブ期間は90日間です。 |
COLD |
COOL ティアよりも大きなコスト削減を提供します(4分の1以下) 最小アーカイブ期間は180日です。 COOL ティアと比較して、 COLD ティアではより長いデータ取得時間があり、最大48時間です。 COLD ストレージティアからのデータ取得操作は、復元操作ごとに最大100万件のファイルをサポートします。 |
アーカイブティアの選択¶
アーカイブティアを選択する際には、以下の要素を考慮してください。
アーカイブコスト:データをアーカイブするための1回限りのコストは、両ティアで同じです。
ストレージコスト: COLD ティアストレージは COOL ティアストレージより安価です。
取得コスト: COLD ティアデータ取得は COOL ティア取得より低コストです。
取得時間:COOL ストレージティアは即時データ取得を提供しますが、COLD ティアの取得には最大48時間かかる場合があります。
重要
アーカイブストレージポリシーをテーブルに添付すると、そのテーブルは、有効期間中、指定されたアーカイブティアに永続的に割り当てられます。新しいポリシーを適用してアーカイブティアを変更することはできません。たとえば、 ALTERTABLE...DROPSTORAGELIFECYCLEPOLICY 内の COOL のアーカイブティアで作成されたポリシーは指定できません。その後、テーブルを変更して、 COLD アーカイブティアで作成されたポリシーを追加します。テーブルのアーカイブティアを変更するには、Snowflakeサポートに連絡し、現在アーカイブされているデータの削除をリクエストしてください。その他の留意点については、 アーカイブストレージポリシー をご参照ください。
詳細な価格設定情報については、Snowflakeサービス利用表 のテーブル3(e)および4(f)をご参照ください。
データアーカイブの詳細については、 ストレージライフサイクルポリシーの作成 および アーカイブストレージの考慮事項 をご参照ください。
考慮事項¶
ストレージライフサイクルポリシーを使用する場合は、次の点を考慮してください。
クラウドプロバイダーのサポート¶
有効期限ポリシー: すべてのクラウドプロバイダーでホストされているアカウントのサポート(Amazon Web Services(AWS)、Microsoft Azure、およびGoogle Cloud)
アーカイブポリシー:
COOL ティア: AWS およびMicrosoft Azureでホストされているアカウントで利用可能。
COLD ティア: AWS でホストされているアカウントのみで利用可能。
サポートされているテーブルと機能¶
サポートされているテーブル:ストレージライフサイクルポリシーは、Snowflakeの標準テーブルと、自動更新されない インタラクティブテーブル でサポートされています。ストレージライフサイクルポリシーの式を評価して適用するために、Snowflakeはテーブル上のガバナンスポリシーを内部的に一時的にバイパスします。
複製:
Snowflakeは、ストレージライフサイクルポリシーとそのテーブルとの関連付けをターゲットアカウントに複製しますが、ポリシーは実行しません。
Snowflakeは COOL または COLD ティアのアーカイブデータを複製しません。フェールオーバー後、ソースアカウントのアーカイブデータはターゲットアカウントでは利用できなくなります。
ターゲットアカウントにフェイルオーバーすると、Snowflakeは元のプライマリアカウントでストレージライフサイクルポリシーの実行を一時停止します。元のプライマリアカウントへのフェールバック後、Snowflakeはポリシーの実行を再開します。
Snowflakeは、フェイルオーバー後でも、セカンダリテーブルに対してセカンダリストレージのライフサイクルポリシーを自動的に実行することはありません。ただし、セカンダリポリシーを 新しい テーブルに添付することで、ターゲットアカウントで使用できます。これらの新しいテーブルに対して、Snowflakeはポリシーを実行します。
クローニング:Snowflakeは、クローンされたテーブルにストレージライフサイクルポリシーを自動的に適用しません。クローングループ内のテーブルにストレージライフサイクルポリシーを適用すると、Snowflakeはその特定のテーブルからのみ行をアーカイブします。ポリシーはクローンに影響を与えません。これにより、標準ストレージティアとアーカイブストレージティアの両方にデータのコピーが作成され、各ティアのストレージ料金が発生します。コスト情報については、ストレージライフサイクルポリシーの請求 をご参照ください。
サポート対象外機能
次の機能には、ストレージのライフサイクルポリシーはサポートされていません。
通常のSnowflakeテーブル、動的テーブル、自動更新を行わないインタラクティブテーブル以外のすべてのオブジェクト型。
Write Once Read Many(WORM)スナップショットは、作成後に変更することができない不変のスナップショットです。
Snowflakeデータ共有を通じて共有されるプロバイダーテーブルとコンシューマーテーブルの両方。
ネイティブアプリ。
外部アクセスおよび外部関数を使用するユーザー定義関数(UDFs)
Python、Java、またはScala UDFs。
ポリシーの動作と実行¶
ストレージのライフサイクルポリシーは、行レベルのアクセスポリシーのガイドライン と類似のパフォーマンスガイドラインを使用し、次の特性で自動的に動作します。
テーブルにストレージライフサイクルポリシーをアタッチすると、Snowflakeは約24時間待ってから初めて実行します。
Snowflakeは、共有コンピューティングリソースを使用して、ストレージライフサイクルポリシーを毎日実行します。ストレージライフサイクルポリシーのコストについては、ストレージライフサイクルポリシーの請求 をご参照ください。
過度に長いアーカイブまたは期限切れの実行を防ぐために、Snowflakeは大規模なデータ操作を小さなチャンクで増分処理します。大規模な操作は、1日の実行では完了せず、複数の日の実行で完了する可能性があります。
ストレージライフサイクルポリシーがテーブルで実行されている場合、Snowflakeは UPDATE、DELETE および MERGE 操作をロックします。この時間中 INSERT および COPY 操作を引き続き実行できます。詳細については、リソースのロック をご参照ください
アーカイブストレージポリシー¶
アーカイブストレージのライフサイクルポリシーがアタッチされているテーブルを操作する場合は、以下の情報を考慮してください。
アーカイブデータへのアクセス:Snowflakeが行をアーカイブした後は、直接クエリできなくなります。アクセスするには、CREATETABLE... FROMARCHIVEOF コマンドを使用して、アーカイブデータのコピーを使用して新しいテーブルを作成します。詳細については、アーカイブデータの取得 をご参照ください。
セキュリティ:|tri-secret-secure|(TSS)を使用して、定期的なキーローテーションでアーカイブデータを保護します。
キー更新:Snowflakeはアーカイブデータをキー更新しません。キーの侵害が疑われる場合は、次の手順を実行します。
CREATETABLE... FROMARCHIVEOF コマンドでアーカイブデータを新しいテーブルに取得します。
必要に応じて、新しいテーブルにデータをアーカイブします。
各テーブルには独自の暗号化キーがあるため、新しいテーブルは新しいキーを効果的に使用します。
キーが侵害された元のテーブルのアーカイブを削除します。
アーカイブティアの制限:
ポリシーの アーカイブティア を COOL から COLD、または COLD から COOL に変更することはできません。代わりに新しいポリシーを作成します。手順については、 ストレージライフサイクルポリシーの再作成 をご参照ください。
テーブルは その有効期間中 1つのアーカイブティアのみ使用できます。たとえば、 COLD アーカイブティアを使用するポリシーを、既に COOL アーカイブティアを使用しているテーブルにアタッチすることはできません。その逆もできません。また、テーブルを変更してポリシーをドロップし、その後別のアーカイブティアを指定するポリシーをアタッチすることもできません。
ポリシーの削除:テーブルからポリシーを削除しても、アーカイブデータはアーカイブストレージに残り、引き続き取得することができます。
テーブルのドロップまたは切り捨て:
テーブルを切り捨てても、そのテーブルのアーカイブデータには影響しません。テーブルを切り捨てた後も、アーカイブストレージからデータを取得することができます。
適用可能な Time Travelデータ保持期間 に UNDROP TABLE を使用してテーブルを復元する場合、Snowflakeはアーカイブストレージ内のすべてのデータも復元します。
テーブルが Fail-safe 期間内の場合、SnowflakeサポートのFail-safeデータ回復ステップを使用して、アーカイブストレージ内のデータを回復できる可能性があります。
ARCHIVE_FOR_DAYS 期間が経過する前に削除したアーカイブストレージ内のテーブルデータには、ストレージコストがかかります。詳細については、 最小ストレージ期間料金 をご参照ください。