垃圾回收

本页面介绍了 Cloud Bigtable 垃圾回收的工作原理,并涵盖以下主题:

  • 垃圾回收的类型
  • 默认垃圾回收设置
  • 何时删除数据
  • 用于复制表的垃圾回收政策的变更

垃圾回收概览

垃圾回收是不断自动从 Bigtable 表中移除过期和过时数据的过程。垃圾回收政策是您创建的一组规则,用于说明何时不再需要特定列族中的数据。

垃圾回收是一个内置的异步后台过程。要真正移除符合垃圾回收条件的数据,可能需要长达一周的时间。垃圾回收按固定的时间表进行,该时间表不会因需要移除的数据量而有所不同。在数据被删除之前,会显示在读取结果中。您可以过滤读取结果以排除此数据。

垃圾回收政策具有以下优势:

  • 使行大小缩减至最小 - 您始终需要防止行无限增大。较大的行会对性能产生负面影响。理想情况下,您不应该让行大小的增长幅度超过 100 MB,上限为 256 MB。如果您不需要保留旧数据或旧版本的当前数据,则使用垃圾回收可以帮助您将每行的大小缩减至最小。
  • 降低费用 - 垃圾回收可确保您无需付费即可存储不再需要或不再使用的数据。在进行压缩并删除符合垃圾回收条件的数据之前,您需要支付过期或过时数据的存储费用。这个过程通常需要几天的时间,但可能需要长达一周的时间。

您可以通过编程方式或使用 cbt 工具设置垃圾回收政策。垃圾回收政策是在列族级设置的。

表中的每个列族都有专属的垃圾回收政策。垃圾回收过程会查找每个列族的当前垃圾回收政策,然后根据政策中的规则删除数据。

时间戳

在 Bigtable 中,一行与一列的交叉可以有多个单元,其中包含该交叉处的值的时间戳版本。每个单元都有一个时间戳。时间戳是自 Unix Epoch 1970-01-01 00:00:00 UTC 开始所经过的微秒数。您可以使用默认时间戳,也可以在发送写入请求时设置时间戳。

单元的时间戳属性可以是“实际”时间戳,反映了写入单元的值的实际时间,也可以是“人工”时间戳。人工时间戳包括序列号、零或时间戳格式的值,这些值不是写入单元的实际时间。在使用人工时间戳之前,请查看有关人工时间戳的用例,包括使用人工时间戳的风险:

垃圾回收的类型

本部分介绍了 Bigtable 中提供的垃圾回收类型。如需了解每种垃圾回收类型的代码示例,请参阅配置垃圾回收

到期值(基于存在时间)

您可以根据每个单元的时间戳设置垃圾回收规则。例如,您可能不希望保留时间戳早于当前日期和时间 30 天以上的任何单元。通过此类垃圾回收规则,您可以设置数据的存留时间 (TTL)。Bigtable 会在垃圾回收期间查看每个列族,并删除任何已过期的单元。

版本数

您可以设置垃圾回收规则,明确指出要为列族中的所有列保留的单元数上限。

例如,如果您只想保留客户的最新用户名和电子邮件地址,则可以创建一个包含这两列的列族,并将该列族的值数上限设置为 1

在另一种情况下,您可能希望保留用户密码哈希的最近 5 个版本以确保这些版本不会重用密码,因此您需要将包含密码列的列族的版本数上限设置为 5。 当 Bigtable 在垃圾回收期间查看列族时,如果已将第 6 个单元写入密码列,则删除最旧的单元以将单元数保持为 5。

到期规则和版本数规则的组合

有两种类型的垃圾回收政策可用于组合以上类型的垃圾回收规则:交叉联合

交叉

交叉式垃圾回收政策会在满足一组给定规则中的所有条件时标记要删除的数据。例如,您可能希望删除超过 30 天的配置文件,但始终为每位用户至少保留一个配置文件。在这种情况下,针对包含配置文件列的列族的交叉式政策包含到期值规则版本数规则。

联合

当数据符合一组给定规则中的任何项时,联合式垃圾回收政策会标记要删除的数据。例如,您可能希望确保为每个用户最多保留 2 条页面浏览量记录,但前提是它们的保留时间不超过 30 天。在这种情况下,系统将为到期值版本数规则设置联合式政策。

垃圾回收的默认设置

列族没有默认 TTL。为列保留的单元数取决于您创建列族所属的列族的方式,如以下部分所述。

HBase 政策

如果您使用 Java 版 HBase 客户端、HBase shell 或其他使用 Java 版 HBase 客户端的工具创建列族,那么除非您更改规则,否则 Bigtable 只会保留列族中每列中的最新单元。此默认设置与 HBase 一致。

所有其他客户端库或工具

如果您使用任何其他客户端库或工具创建列族,则 Bigtable 会在列族的每一列中保留无限多个单元。这包括使用 gcloudcbt tool 创建的列族。如果您想要限制版本数,则必须更改列族的垃圾回收政策。

何时删除数据

垃圾回收是一个连续的过程。在此过程中,Bigtable 会检查每个列族的规则,并相应地删除过期和过时的数据。通常,此过程从数据与实际要删除的数据对应的规则中的条件匹配之时开始,可能需要长达一周的时间。您无法更改垃圾回收的时间。

由于数据可能需要长达一周时间才能被垃圾回收,因此您不应该仅仅依靠垃圾回收政策来确保读取请求返回所需的数据。应始终对读取请求应用过滤条件,以排除与垃圾回收规则相同的值。您可以通过限制每列的单元数或通过指定时间戳范围进行过滤。

例如,假设列族的垃圾回收规则设置为仅保留配置文件的最近 5 个版本,并且已存储 5 个版本。在写入配置文件的新版本后,最旧的单元可能需要长达一周时间才能被垃圾回收。因此,为了避免读取第 6 个值,您应始终滤除 5 个最新版本之外的所有内容。

在进行压缩并删除该数据之前,您需要支付过期数据的存储费用。

垃圾回收具有追溯性:设置新的垃圾回收政策后,在接下来的几天内,该政策将应用于表中的所有数据。如果新政策比以前的政策更严格,则旧数据会在后台工作开始执行时被删除,包括政策更改之前写入的数据。

如果您要确保标记为垃圾回收的数据被删除,可以查询表并将数据与预期结果进行比较。您还可以在 Google Cloud Console 中监控表大小。如果表的大小没有缩减,则可能反映了垃圾回收政策未按预期工作,但请注意垃圾回收会延迟执行。

用于复制表的垃圾回收政策的变更

如果表位于单集群实例中,则借助 Bigtable,您可以随时修改或删除列族的政策。另一方面,某些限制适用于使用复制功能的实例中的表。这些限制可保护您的数据。

您可以在复制表中修改列族的版本数上限。但是,如果您减少列族的版本数,则所有复制集群可能需要长达一周时间才能反映新的较小数量。因此,在读取数据时应始终使用过滤条件。

Bigtable 不允许您在复制表中延长列族的 TTL。为了了解原因,请假设您要将列族的 TTL 从 30 天更改为 60 天。基于存在时间的垃圾回收可以在每个集群中单独运行。因此,在您更改政策时,垃圾回收可能已删除表的一个副本中保留 31 天的值,但不会删除另一个副本中的值。在这种情况下更改垃圾回收政策可能会使副本近一个月不同步。

出于同样的原因,Bigtable 不允许删除复制表中列族的基于存在时间的垃圾回收政策。

后续步骤