存留时间 (TTL) 概览

通过存留时间 (TTL)，您可以设置政策，以定期从 Spanner 表中删除数据。移除不需要的数据：

  • 降低存储空间和备份费用。
  • 减少数据库扫描某些查询的行数，从而可能提高查询性能。
  • 有助于遵守旨在限制某些类型的数据保留期限的法规或行业准则。

TTL 是常规清理活动的理想选择。它在后台持续运行，定期批量删除符合条件的数据。数据通常会在失效日期后的 72 小时内删除。每次删除都需要在数据库的副本之间复制主键，这会导致复制费用。 如需了解详情，请参阅数据复制价格。 当 TTL 不会被删除时，它不会立即使数据失效，也不会在查询中隐藏这些数据。TTL 也不会在插入数据时检查数据，因此不会阻止您插入具有过期时间戳的行。

TTL 的设计能够最大限度地减少对其他数据库工作负载的影响。TTL 清扫器进程在后台以系统低优先级运行。与最终用户查询相比，它能更高效地在时间和可用实例资源之间分配工作，并且包含重试逻辑，以确保以最小的处理开销完成端到端清理。

另一个后台压缩过程（通常在 7 天内）从已删除的行中收回存储空间。

TTL 的工作原理是什么？

您可以在数据库架构中定义行删除政策，以设置 Spanner 表的 TTL。此政策允许 Spanner 定期删除不需要的数据。TTL 政策具有以下特征：

  • 每个表都可以有自己的政策。
  • 每个表只能指定一个 TTL 政策。
  • 您需要为 GoogleSQL 方言数据库和 PostgreSQL 方言数据库分别设置 TTL。
  • 如果行的时间戳设置为 NULL，则 TTL 政策不会删除该行。
  • 如果插入的数据带有过期时间戳，系统会在下一个 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 按交易标记进行过滤的示例。

后续步骤