ストレージのライフサイクルポリシー

ストレージライフサイクルポリシー は、標準およびインタラクティブなSnowflakeテーブルのデータライフサイクルを自動的に管理するスキーマレベルのオブジェクトです。これらのポリシーを使用して、データの年齢やその他の基準など、定義した条件に基づいて、特定のテーブル行をアーカイブまたは期限切れにします。Snowflakeは、共有コンピューティングリソースを使用して、これらのポリシーを毎日自動的に実行します。

ストレージライフサイクルポリシーの仕組み

ストレージライフサイクルポリシーワークフローの概要

ストレージライフサイクルポリシーを開始するには、次のステップを実行します。

  1. ポリシーを作成する アーカイブまたは期限切れにする行を識別する式を使用します。

  2. ポリシーを1つ以上のテーブルに添付する

テーブルにストレージライフサイクルポリシーをアタッチすると、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はアーカイブデータをキー更新しません。キーの侵害が疑われる場合は、次の手順を実行します。

    1. CREATETABLE... FROMARCHIVEOF コマンドでアーカイブデータを新しいテーブルに取得します。

    2. 必要に応じて、新しいテーブルにデータをアーカイブします。

      各テーブルには独自の暗号化キーがあるため、新しいテーブルは新しいキーを効果的に使用します。

    3. キーが侵害された元のテーブルのアーカイブを削除します。

  • アーカイブティアの制限:

    • ポリシーの アーカイブティア を COOL から COLD、または COLD から COOL に変更することはできません。代わりに新しいポリシーを作成します。手順については、 ストレージライフサイクルポリシーの再作成 をご参照ください。

    • テーブルは その有効期間中 1つのアーカイブティアのみ使用できます。たとえば、 COLD アーカイブティアを使用するポリシーを、既に COOL アーカイブティアを使用しているテーブルにアタッチすることはできません。その逆もできません。また、テーブルを変更してポリシーをドロップし、その後別のアーカイブティアを指定するポリシーをアタッチすることもできません。

  • ポリシーの削除:テーブルからポリシーを削除しても、アーカイブデータはアーカイブストレージに残り、引き続き取得することができます。

  • テーブルのドロップまたは切り捨て:

    • テーブルを切り捨てても、そのテーブルのアーカイブデータには影響しません。テーブルを切り捨てた後も、アーカイブストレージからデータを取得することができます。

    • 適用可能な Time Travelデータ保持期間UNDROP TABLE を使用してテーブルを復元する場合、Snowflakeはアーカイブストレージ内のすべてのデータも復元します。

    • テーブルが Fail-safe 期間内の場合、SnowflakeサポートのFail-safeデータ回復ステップを使用して、アーカイブストレージ内のデータを回復できる可能性があります。

    • ARCHIVE_FOR_DAYS 期間が経過する前に削除したアーカイブストレージ内のテーブルデータには、ストレージコストがかかります。詳細については、 最小ストレージ期間料金 をご参照ください。