关于存留时间 (TTL)

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

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

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

TTL 是常规清理活动的理想选择。它在后台持续运行,定期批量删除符合条件的数据。数据通常会在失效日期后的 72 小时内删除。当数据符合删除条件时,TTL 不会立即使数据失效或对查询隐藏数据。TTL 在插入时也不会检查数据,因此不会阻止您插入包含过期时间戳的行。

TTL 的设计能够最大限度地减少对其他数据库活动的影响。它比最终用户查询更有效地并行工作,并且包括重试逻辑,以确保进行端到端清理。

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

TTL 的工作原理是什么?

您可以在数据库架构中定义行删除政策,对 Spanner 表设置 TTL,以允许 Spanner 定期删除不需要的数据。每个表都可以有自己的政策。每个表只能指定一个 TTL 政策。您为 Google 标准 SQL 方言数据库和 PostgreSQL 方言数据库设置 TTL 的方式有所不同。

Google 标准 SQL TTL

使用 Google SQL,您可以通过指定时间戳时间间隔来确定行何时可以删除,从而定义行删除政策;例如,上次更新日期加 30 天。

后台系统每天检查符合条件的行。它将并行执行的实际删除并行执行,这些删除接近数据存储位置。每个批次都会以一致的时间戳在自己的事务中运行。因此,给定批次中的行以及所有索引和交错子项一定会以原子方式删除。但是,不同批次的删除操作发生在不同的事务中。

由于这是一个异步后台过程,因此从延迟到等待符合标准为止。延迟时间通常少于 72 小时。因此,在 TTL 到期后,行可能会在表中最多保留三天;例如,如果表的行删除政策删除超过四天的行,则表可能包含最长七天的行以及较早的、不可删除的行。

如需了解有关如何创建 Google 标准 SQL 行删除政策的分步说明,请参阅创建 TTL 政策

将 TTL 与 PostgreSQL 搭配使用

借助 PostgreSQL,数据库所有者可以在 CREATE TABLEALTER 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 字段设置为 RowDeletionPolicyis_system_transaction 字段设置为 true。然后,变更流读取器能够滤除所有 TTL 记录或除 TTL 记录以外的所有记录,具体取决于相应用例。请参阅使用 Beam 按交易标记过滤的示例。