关于 TTL

概览

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

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

TTL 是常规清理活动的理想选择。它在后台持续运行,定期批量删除符合条件的数据。数据通常会在失效日期后的 72 小时内删除。当 TTL 不会被删除时,它不会立即使数据失效,也不会在查询中隐藏这些数据。

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

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

TTL 的工作原理是什么?

数据库所有者通过在数据库架构中定义行删除政策来设置表的 TTL。每个表都可以有自己的政策。每个表只能指定一个行删除政策。

行删除政策指定时间戳时间间隔来确定行何时可以删除行;例如,上次更新日期加 30 天。 如需了解实际语法,请参阅使用 TTL

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

由于这是一个异步后台过程,因此从延迟到等待符合标准为止。延迟时间通常少于 72 小时。因此,在 TTL 过期后,行可能会在您的表中保留最多 3 天;例如,具有删除早于 4 天的行的行删除政策的表可能包含最多 7 天的行以及更旧的不可删除的行。

备份和 TTL

恢复备份

从备份恢复数据库时,系统会自动删除源数据库上配置的所有行删除政策。这样可以防止 Cloud Spanner 在备份恢复后立即删除过期数据。您需要手动重新创建行删除政策

数据一致性

备份是数据在特定时间点的一致快照。同样,Dataflow 导出作业会以固定的时间戳读取整个表。TTL 垃圾回收机制会在后台不断收集符合条件的行。每个由 TTL 发出的 DELETE 都以与用户事务相同的方式分配的时间戳。备份不包含任何时间戳早于备份时间的 DELETE。备份可以包含可能有资格删除 TTL 但尚未完成 TTL 的行。