Snowflakeの永続テーブル、削除後も7日間の保管料

要約

ゼロという設定値には、倹約家を喜ばせる響きがある。Snowflakeの永続テーブルでTime Travelをゼロ日にしても、その先には7日間のFail-safeが待っている。利用者が過去の状態を直接調べる窓を閉じても、事業者が復旧を試みるための保管は続く。

削除したテーブルが一覧から消え、残されたデータには料金がかかる。これがSnowflakeの公開する保護の仕組みだ。予算削減を任された人に必要なのは、削除処理の完了数に加えて、どのデータがいつ保管を終えるかという見取り図になる。

ストレージ料金の説明は、稼働中のデータ、Time Travelの履歴、Fail-safe、クローンが参照する関連データを課金対象として挙げる。テーブルは圧縮され、圧縮後のサイズが計算に使われる。画面上のテーブル数を減らす作業と、請求対象の容量が減る時点は別々に進む。

Fail-safeの文書によれば、この期間は7日間で変更できず、Time Travelの保持期間が終わると始まる。Time Travelの通常の操作では履歴を使えなくなり、復旧はSnowflakeのサポート経由になる。

対象は、ほかの回復方法を試した後の重大な運用障害などだ。復旧はベストエフォートで行われ、数時間から数日かかる場合がある。さらに、復旧処理には課金対象のサーバーレス計算資源が使われる。データを残す費用と、実際に取り戻す処理の費用がそれぞれ存在する。

誤削除や障害の損失が大きいデータにとって、もう一度救出を試せる価値は高い。その選択肢を確保するため、利用者が直接触れなくなった履歴も場所を占め続ける。保護機能の価値と保管料は同じ設計から生じている。

履歴ストレージの料金説明は、基本となる期間を次のように整理している。

テーブル種別	Time Travel	その後のFail-safe
Standard Editionの永続テーブル	0日または1日	7日
Enterprise Edition以上の永続テーブル	0～90日	7日
transient	0日または1日	なし
temporary	0日または1日。削除かセッション終了まで	なし

長時間のTime Travelクエリは、完了するまでFail-safeへの移行を遅らせる。状態の変更にはバックグラウンド処理も関わる。表にある日数は保護段階の基本設計を示し、個々の参照関係や処理状況が実際の保管終了に関わる。

Time Travelの仕様には、保持期間を10日から1日にする例がある。直近1日分はTime Travelに残り、2～10日前の履歴はFail-safeへ移る。利用者が直接復元できる範囲が狭くなり、古いデータは次の保護段階へ進む。

削除済みテーブルでは、親の設定変更が届かない場合も明示されている。スキーマから90日を継承したテーブルを削除し、その後でスキーマを1日に変更しても、削除済みテーブルは90日を維持する。文書上、そのオブジェクト自体の期間を変えるには、いったん復元してから変更する。

新しい方針を設定した日から、過去の削除分まで一斉に短くなる仕組みではない。アカウントの最低保持期間が、個別設定より長い有効期間を与えることもある。現場のゼロ日という表示には、上位の設定も合わせて読む必要がある。

こうした条件は、テーブル作成時点の選択を後日のコストに結び付ける。プロジェクト終了時に整理を担当する人は、その場で作られたわけではない保管義務を引き受けることになる。

クローンのストレージ説明によると、ゼロコピーのクローンは作成時に既存のマイクロパーティションを共有する。変更が加わると、それぞれが所有する新しいパーティションが生まれ、各オブジェクトが独自のライフサイクルを持つ。

開発用に作ったスナップショットが、元のテーブルでは不要になったデータを参照し続けることもある。TABLE_STORAGE_METRICSは、削除後もクローンの参照で保持されるデータを区別して示す。この区分には、テーブルデータを残すWORMバックアップも含まれる。

同ビューの主な区分は、稼働中、Time Travel、Fail-safe、クローンなどのために保持するバイトだ。料金が発生する削除済みテーブルも表示に残る。同じ名前を再作成すると、別の版が独自の履歴を持って並ぶ場合がある。業務上は同じ名前でも、請求を追うには各オブジェクトの識別情報が必要になる。

Account Usageの反映には最大90分の遅れがある。削除済みの行が表示されていても、主要4区分がすべてゼロならストレージ料金は生じない。個別アカウントの残存費用を算出するには、圧縮後の保持バイト、有効な保持方針、適用単価が要る。

transientテーブルにはFail-safeがなく、Time Travelは最大1日になる。この1日は追加の履歴保護に関する上限だ。テーブルが存在する間の稼働データは引き続き課金されるため、数週間置いておけば稼働ストレージも数週間使う。

再生成できる作業データなら、保護を短くする選択は合理的になり得る。履歴が切れた後にFail-safeで取り戻す道はなくなるので、再構築の時間、計算資源、その間の業務停止を一緒に評価する。再作成が難しいデータでは、保護を買う方が運用全体で安くつく場合もある。

temporaryテーブルではセッションがもう一つの区切りになる。削除またはセッション終了で履歴の保持も終わるが、接続を切るだけではセッションは終了しない。利用者がクライアントを閉じた時点と、データが片付く時点もずれ得る。

Snowflakeは、保護の長さとデータの寿命を選ぶ手段を用意している。その選択に引き取り手が必要だ。削除処理の成功を受け取る担当者に加え、残った復旧可能性に誰がいくら払うのかを決める担当者がいる。