有効期間（TTL）の概要

有効期間（TTL）を使用すると、Spanner テーブルからデータを定期的に削除するポリシーを設定できます。不要なデータの削除:

  • ストレージとバックアップの費用が削減されます。
  • 一部のクエリをスキャンする場合のデータベースの行数を削減することで、クエリのパフォーマンス向上を図ります。
  • 特定の種類のデータの保持期間を制限する規制や業界ガイドラインを遵守するのに役立ちます。

TTL は、定期的なクリーンアップ作業に最適です。それはバックグラウンドで継続的に実行され、有効なデータをバッチで定期的に削除します。データは通常、有効期限が切れた後 24 時間以内に削除されます。削除するたびに、データベースのレプリカ間で主キーのレプリケーションが必要になるため、レプリケーション コストが発生します。詳細については、データのレプリケーション料金をご覧ください。TTL は、データが削除対象になったときに、データを直ちに無効にしたり、クエリから非表示にしたりしません。また、TTL では挿入されたデータもチェックされないため、期限切れのタイムスタンプを持つ行の挿入はブロックされません。

TTL は他のデータベース ワークロードへの影響を最小限にするように設計されています。TTL のスイーパー プロセスは、優先度の低いシステムとして、バックグラウンドで動作します。エンドユーザーのクエリよりも効率的に、時間と利用可能なインスタンス リソースにまたがり作業を分散させ、処理のオーバーヘッドを最小限に抑えながらエンドツーエンドのクリーンアップを保証する再試行ロジックを搭載しています。

別のバックグラウンド圧縮プロセスにより、通常は 7 日以内に、削除された行からストレージが回収処理されます。

TTL の仕組み

データベース スキーマで行削除ポリシーを定義することで、Spanner テーブルに TTL を設定できます。このポリシーにより、Spanner は不要なデータを定期的に削除できます。TTL ポリシーには次の特徴があります。

  • 各テーブルに独自のポリシーを設定できます。
  • テーブルごとに指定できる TTL ポリシーは 1 つだけです。
  • GoogleSQL 言語データベースと PostgreSQL 言語データベースでは、TTL の設定方法が異なります。
  • TTL ポリシーでは、タイムスタンプが NULL に設定されている行は削除されません。
  • 期限切れのタイムスタンプで挿入されたデータは、次回の 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 を使用してトランザクション タグでフィルタリングするの例をご覧ください。

次のステップ