有効期間（TTL）を使用すると、Spanner テーブルからデータを定期的に削除するポリシーを設定できます。不要なデータの削除:
- ストレージとバックアップの費用を削減する。
- データベースが一部のクエリをスキャンする必要がある行数を減らし、クエリのパフォーマンスが向上する可能性があります。
- 特定の種類のデータに対する保持期間を制限する規制または業界ガイドラインを遵守するのに役立ちます。
TTL は、定期的なクリーンアップ アクティビティに最適です。これはバックグラウンドで継続的に実行され、適格データを定期的にバッチで削除します。データは通常、有効期限が切れた後 72 時間以内に削除されます。TTL によってデータがすぐに無効になったり、クエリが削除対象になったときのクエリに表示されなくなることはありません。また、TTL では挿入されたデータもチェックされないため、期限切れのタイムスタンプを持つ行の挿入はブロックされません。
TTL は他のデータベース アクティビティへの影響を最小限にするように設計されています。エンドユーザーのクエリよりも効率的に作業を並列化し、エンドツーエンドのクリーンアップを保証するリトライ ロジックを搭載しています。
別のバックグラウンド圧縮プロセスにより、通常は 7 日以内に、削除された行からストレージが回収処理されます。
TTL の仕組み
データベース スキーマで行削除ポリシーを定義することによって Spanner テーブルに TTL を設定できます。これにより、Spanner は不要なデータを定期的に削除できます。各テーブルには独自のポリシーを設定できます。テーブルごとに指定できる TTL ポリシーは 1 つだけです。GoogleSQL 言語データベースと PostgreSQL 言語データベースでは、TTL の設定方法が異なります。
GoogleSQL での TTL
GoogleSQL を使用して、行削除ポリシーを定義します。そのためには、タイムスタンプと間隔を指定して、行が削除可能になるタイミング（たとえば最終更新日 + 30 日）を決定します。
バックグラウンド システム プロセスは、対象の行を毎日チェックします。実際の削除が並列化され、データが内部で保存されている場所に近い場所で実行されます。各バッチは、一貫したタイムスタンプで独自のトランザクションで実行されます。したがって、特定のバッチ内の行は、インデックスとインターリーブされた子とともに、アトミックに削除されます。ただし、バッチ間の削除は異なるトランザクションで行われます。
これは非同期のバックグラウンド プロセスであるため、削除資格と削除の間に遅延があります。通常、この遅延は 72 時間未満です。その結果、TTL が期限切れになってから最大 3 日間、テーブルに行が残ることがあります。たとえば、4 日を超える行を削除する行削除ポリシーがあるテーブルには、最大 7 日前までの行と、削除できない古い行が含まれる場合があります。
GoogleSQL の行削除ポリシーを作成する手順については、TTL ポリシーの作成をご覧ください。
PostgreSQL を使用する TTL
PostgreSQL では、データベース オーナーは CREATE TABLE または ALTER TABLE ステートメントで TTL INTERVAL 句を使用して行削除ポリシーを定義できます。
PostgreSQL テーブルに行削除ポリシーを設定するには、テーブルにデータ型 TIMESTAMPTZ の列が必要です。TTL INTERVAL 句はこの列を使用して、行が削除可能になる間隔を指定します。
句は日数で評価される必要があります。たとえば、'3
DAYS' は許可され、'4 DAYS 2 MINUTES - 2 MINUTES' も許可されますが、'4 DAYS 3
MINUTES' は許容されず、エラーが返されます。負の数値は使用できません。
TTL ガベージ コレクションは、適格な行をバックグラウンドで継続的に削除します。これは非同期のバックグラウンド プロセスであるため、削除資格と削除の間に遅延があります。テーブルには、TTL の削除の対象であるものの、TTL がまだ完了していない行が含まれる場合があります。通常、この遅延は 72 時間未満です。
PostgreSQL の行削除ポリシーを作成する方法については、TTL ポリシーを作成するをご覧ください。
バックアップと TTL
バックアップの復元
バックアップからデータベースを復元すると、ソース データベースで構成された行削除ポリシーが自動的に破棄されます。これにより、バックアップが復元されるとすぐに Spanner が期限切れのデータを削除することを防止できます。そのため、TTL は手動で再構成する必要があります。
データの整合性
バックアップは、特定の時点（version_time）でのデータの一貫性のあるスナップショットです。バックアップには、TTL の削除の対象になる可能性があるものの、TTL が完了していない行が含まれる場合があります。同様に、Dataflow エクスポート ジョブは、テーブル全体を固定タイムスタンプで読み取ります。
監査
TTL では、変更ストリームを介して削除の監査がサポートされています。変更ストリーム データレコードは、データベースに対する TTL 変更を追跡するため、transaction_tag フィールドを RowDeletionPolicy に設定し、is_system_transaction フィールドを true に設定します。変更ストリームのリーダーは、ユースケースに応じてすべての TTL レコード、または TTL レコードを除くすべてのレコードを除外できます。Beam を使用してトランザクション タグでフィルタする例をご覧ください。