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

主な機能¶

ストレージのライフサイクルポリシーは、Snowflakeデータを管理するために次の利点を提供します。

ストレージコストの削減

ストレージライフサイクルポリシーは、古いデータをより費用対効果の高い アーカイブティア に自動的に移動することで、コストの最適化を支援します。長期間保持する必要があるが、アクセス頻度が低いデータの場合、アーカイブストレージにより、標準ストレージティアと比較してストレージコストを大幅に削減できます。

規制コンプライアンス

規制基準に従ってデータをアーカイブまたは期限切れにするポリシーを構成することで、コンプライアンス要件を自動的に満たします。有効期限が切れる前の特定の時間のデータをアーカイブすることも、アーカイブせずに直接期限切れにすることもできます。これにより、データ管理は組織のガバナンス基準に従って行われます。

簡単なデータ管理

ストレージライフサイクルポリシーは、アーカイブルールと有効期限ルールを自動的に実行することで、手作業によるデータ管理タスクを排除します。詳細については、 ストレージライフサイクルポリシーの監視 をご参照ください。

柔軟なデータ取得

必要な行のみを含む新しいテーブルを作成することで、正確に アーカイブデータを取得する ことが可能です。WHERE 句の簡単なコマンドを使用して、復元するアーカイブデータを正確に指定します。

アーカイブティアの選択¶

アーカイブティアを選択する際は、以下の点に注意してください。

• アーカイブコスト:データをアーカイブするための1回限りのコストは、両ティアで同じです。

• ストレージコスト: COLD ティアストレージは COOL ティアストレージより安価です。

• 取得コスト: COLD ティアデータ取得は COOL ティア取得より低コストです。

• 取得時間:COOL ストレージティアは即時データ取得を提供しますが、COLD ティアの取得には最大48時間かかる場合があります。

詳細な価格設定情報については、Snowflakeサービス利用表 のテーブル3（e）および4（f）をご参照ください。

データアーカイブの詳細については、ストレージライフサイクルポリシーの作成 および アーカイブストレージの考慮事項 をご参照ください。

クラウドプロバイダーのサポート¶

• 有効期限ポリシー:すべてのクラウドプロバイダーでホストされているアカウントでサポートされます（AWSAzure、およびGoogle Cloud）

• アーカイブポリシー:現在、AWS でホストされているアカウントでのみ利用できます。

サポートされているテーブルと機能¶

• サポートされているテーブル:ストレージのライフサイクルポリシーは、標準のSnowflakeテーブルでサポートされています。ストレージライフサイクルポリシー式を評価して適用するために、Snowflakeは内部的および一時的にテーブルに対するガバナンスポリシーをバイパスします。

• 複製:

  • Snowflakeは、ストレージライフサイクルポリシーとそのテーブルとの関連付けをターゲットアカウントに複製しますが、ポリシーは実行しません。

  • ターゲットアカウントにフェイルオーバーすると、Snowflakeは元のプライマリアカウントでストレージライフサイクルポリシーの実行を一時停止します。元のプライマリアカウントへのフェールバック後、Snowflakeはポリシーの実行を再開します。

  • Snowflakeは、フェイルオーバー後でも、セカンダリテーブルに対してセカンダリストレージのライフサイクルポリシーを自動的に実行することはありません。ただし、セカンダリポリシーを 新しい テーブルに添付することで、ターゲットアカウントで使用できます。これらの新しいテーブルに対して、Snowflakeはポリシーを実行します。

• クローニング:Snowflakeは、クローンされたテーブルにストレージライフサイクルポリシーを自動的に適用しません。クローングループ内のテーブルにストレージライフサイクルポリシーを適用すると、Snowflakeはその特定のテーブルからのみ行をアーカイブします。ポリシーはクローンに影響を与えません。これにより、標準ストレージティアとアーカイブストレージティアの両方にデータのコピーが作成され、各ティアのストレージ料金が発生します。コスト情報については、ストレージライフサイクルポリシーの請求 をご参照ください。

• サポート対象外機能

  次の場合は、ストレージのライフサイクルポリシーはサポートされていません。

  • 通常のSnowflakeテーブルと動的テーブル以外のすべてのオブジェクトタイプ。

  • Write Once Read Many（WORM）スナップショットは、作成後に変更することができない不変のスナップショットです。

  • Snowflakeデータ共有を通じて共有されるテーブル（プロバイダーテーブルとコンシューマーテーブルの両方）

  • ネイティブアプリ。

  • 外部アクセスおよび外部関数を使用するユーザー定義関数（UDFs）

  • Python、Java、またはScala UDFs。

ポリシーの動作と実行¶

ストレージのライフサイクルポリシーは、行レベルのアクセスポリシーのガイドライン と類似のパフォーマンスガイドラインを使用し、次の特性で自動的に動作します。

• テーブルにストレージライフサイクルポリシーをアタッチすると、Snowflakeは約24時間待ってから初めて実行します。

• Snowflakeは、共有コンピューティングリソースを使用して、ストレージライフサイクルポリシーを毎日実行します。ストレージライフサイクルポリシーのコストについては、ストレージライフサイクルポリシーの請求 をご参照ください。

• 過度に長いアーカイブまたは期限切れの実行を防ぐために、Snowflakeは大規模なデータ操作を小さなチャンクで段階的に処理します。大規模な操作は1日1回の実行では完了しない可能性があり、代わりに1日の複数の実行で完了する可能性があります。

• ストレージライフサイクルポリシーがテーブルで実行されている場合、Snowflakeは UPDATE、DELETE および MERGE 操作をロックします。この時間中 INSERT および COPY 操作を引き続き実行できます。詳細については、リソースのロック をご参照ください

アーカイブストレージポリシー¶

アーカイブストレージライフサイクルポリシーがアタッチされているテーブルを操作する場合

• アーカイブデータへのアクセス:Snowflakeが行をアーカイブした後は、直接クエリできなくなります。アクセスするには、CREATETABLE... FROMARCHIVEOF コマンドを使用して、アーカイブデータのコピーを使用して新しいテーブルを作成します。詳細については、アーカイブデータの取得 をご参照ください。

• セキュリティ:|tri-secret-secure|（TSS）を使用して、定期的なキーローテーションでアーカイブデータを保護します。

• キー更新:Snowflakeはアーカイブデータをキー更新しません。キーの侵害が疑われる場合は、次の回避策を使用してください。

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

  2. 必要に応じて、新しいテーブルにデータをアーカイブします。各テーブルには独自の暗号化キーがあるため、新しいテーブルは新しいキーを効果的に使用します。

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

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

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

  • テーブルは1つのアーカイブティアのみ使用できます。既に COOL アーカイブを使用しているテーブルへ COLD ポリシーを添付することはできません。

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

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

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

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

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

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