有効期間（TTL）によって、Spanner テーブルからデータを定期的に削除するポリシーを設定できます。不要なデータの削除:
- ストレージとバックアップの費用が削減されます。
- データベースが一部のクエリに対してスキャンする必要がある行数が減り、クエリのパフォーマンスが向上する可能性があります。
- 特定の種類のデータの保持期間を制限する規制や業界ガイドラインを遵守するのに役立ちます。
TTL は、定期的なクリーンアップ アクティビティに最適です。それはバックグラウンドで継続的に実行され、有効なデータをバッチで定期的に削除します。データは通常、有効期限が切れた後 72 時間以内に削除されます。TTL によってデータがすぐに無効になったり、クエリが削除対象になったときのクエリに表示されなくなることはありません。また、TTL では挿入されたデータもチェックされないため、期限切れのタイムスタンプを持つ行の挿入はブロックされません。
TTL は他のデータベース アクティビティへの影響を最小限にするように設計されています。エンドユーザーのクエリよりも効率的に作業を並列化し、エンドツーエンドのクリーンアップを保証するリトライ ロジックを搭載しています。
別のバックグラウンド圧縮プロセスにより、通常は 7 日以内に、削除された行からストレージが回収処理されます。
TTL の仕組み
データベース スキーマで行削除ポリシーを定義することで、Spanner テーブルに TTL を設定できます。これにより、Spanner は不要なデータを定期的に削除できます。各テーブルには独自のポリシーを設定できます。テーブルごとに 1 つの TTL ポリシーのみを指定できます。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 1 つを除くすべてのレコードをフィルタリングして除外できます。Beam を使用してトランザクション タグでフィルタリングする例をご覧ください。