垃圾回收概览
本页介绍了 Bigtable 中的垃圾回收工作原理，并涵盖以下主题：
- 垃圾回收的类型
- 默认垃圾回收设置
- 何时删除数据
- 用于复制表的垃圾回收政策的变更
垃圾回收概览
垃圾回收是不断自动从 Bigtable 表中移除过期和过时数据的过程。垃圾回收政策是您创建的一组规则，用于说明何时不再需要特定列族中的数据。
垃圾回收是一个内置的异步后台过程。要真正移除符合垃圾回收条件的数据，可能需要长达一周的时间。垃圾回收按固定的时间表进行，该时间表不会因需要移除的数据量而有所不同。在数据被删除之前，会显示在读取结果中。您可以过滤读取结果以排除此数据。
垃圾回收政策具有以下优势：
- 使行大小缩减至最小 - 您始终需要防止行无限增大。较大的行会对性能产生负面影响。理想情况下，您不应该让行大小的增长幅度超过 100 MB，上限为 256 MB。如果您不需要保留旧数据或旧版本的当前数据，则使用垃圾回收可以帮助您将每行的大小缩减至最小。
- 降低费用 - 垃圾回收可确保您无需付费即可存储不再需要或不再使用的数据。在进行压缩并删除符合垃圾回收条件的数据之前，您需要支付过期或过时数据的存储费用。这个过程通常需要几天的时间，但可能需要长达一周的时间。
您可以通过编程方式或使用 cbt CLI设置垃圾回收政策。垃圾回收政策是在列族级设置的。
表中的每个列族都有专属的垃圾回收政策。垃圾回收过程会查找每个列族的当前垃圾回收政策，然后根据政策中的规则删除数据。
时间戳
在 Bigtable 中，一行与一列的交叉可以有多个单元，其中包含该交叉处的值的时间戳版本。每个单元都有一个时间戳。时间戳是自 Unix Epoch 1970-01-01 00:00:00 UTC 开始所经过的微秒数。您可以使用默认时间戳，也可以在发送写入请求时设置时间戳。
您发送到 Bigtable 的时间戳必须是微秒值，精确度最高为毫秒级。精度为微秒的时间戳（例如 3023483279876543）会被拒绝。在此示例中，可接受的时间戳值为 3023483279876000。
单元的时间戳属性可以是“实际”时间戳，反映了写入单元的值的实际时间，也可以是“人工”时间戳。人工时间戳包括序列号、零或时间戳格式的值，这些值不是写入单元的实际时间。在使用人工时间戳之前，请查看有关人工时间戳的用例，包括使用人工时间戳的风险：
确保在发送写入请求时设置默认时间戳，除非您需要支持具有人工时间戳的用例。
垃圾回收的类型
本部分介绍了 Bigtable 中提供的垃圾回收类型。如需了解每种垃圾回收类型的代码示例，请参阅配置垃圾回收。
到期值（基于存在时间）
您可以根据每个单元的时间戳设置垃圾回收规则。例如，您可能不希望保留时间戳早于当前日期和时间 30 天以上的任何单元。通过此类垃圾回收规则，您可以设置数据的存留时间 (TTL)。Bigtable 会在垃圾回收期间查看每个列族，并删除任何已过期的单元。
版本数
您可以设置垃圾回收规则，明确指出要为列族中的所有列保留的单元数上限。
例如，如果您只想保留客户的最新用户名和电子邮件地址，则可以创建一个包含这两列的列族，并将该列族的值数上限设置为 1。
在另一种情况下，您可能希望保留用户密码哈希的最近 5 个版本以确保这些版本不会重用密码，因此您需要将包含密码列的列族的版本数上限设置为 5。
当 Bigtable 在垃圾回收期间查看列族时，如果已将第 6 个单元写入密码列，则删除最旧的单元以将单元数保持为 5。
到期规则和版本数规则的组合
您可以组合使用到期规则和版本号规则来进行垃圾回收。组合类型包括交集、并集和嵌套。如需查看配置示例，请参阅基于多个条件的垃圾回收。
交叉
交叉式垃圾回收政策会在满足一组给定规则中的所有条件时标记要删除的数据。例如，您可能希望删除超过 30 天的配置文件，但始终为每位用户至少保留一个配置文件。在这种情况下，针对包含配置文件列的列族的交叉式政策包含到期值规则和版本数规则。
联合
当数据符合一组给定规则中的任何项时，联合式垃圾回收政策会标记要删除的数据。例如，您可能希望确保为每个用户最多保留 2 条页面浏览量记录，但前提是它们的保留时间不超过 30 天。在这种情况下，系统将为到期值或版本数规则设置联合式政策。
嵌套
嵌套式垃圾回收政策同时包含并集规则和交集规则。
垃圾回收的默认设置
列族没有默认 TTL。为列保留的单元数取决于您创建列族所属的列族的方式，如以下部分所述。
HBase 政策
如果您使用 Java 版 HBase 客户端、HBase shell 或其他使用 Java 版 HBase 客户端的工具创建列族，那么除非您更改规则，否则 Bigtable 只会保留列族中每列中的最新单元。此默认设置与 HBase 一致。
所有其他客户端库或工具
如果您使用任何其他客户端库或工具创建列族，则 Bigtable 会在列族的每一列中保留无限多个单元。这包括使用 gcloud 和 cbt CLI 创建的列族。如果您想要限制版本数，则必须更改列族的垃圾回收政策。
何时删除数据
垃圾回收是一个连续的过程。在此过程中，Bigtable 会检查每个列族的规则，并相应地删除过期和过时的数据。通常，此过程从数据与实际要删除的数据对应的规则中的条件匹配之时开始，可能需要长达一周的时间。您无法更改垃圾回收的时间。
由于数据可能需要长达一周时间才能被垃圾回收，因此您不应该仅仅依靠垃圾回收政策来确保读取请求返回所需的数据。应始终对读取请求应用过滤条件，以排除与垃圾回收规则相同的值。您可以通过限制每列的单元数或通过指定时间戳范围进行过滤。
例如，假设列族的垃圾回收规则设置为仅保留配置文件的最近 5 个版本，并且已存储 5 个版本。在写入配置文件的新版本后，最旧的单元可能需要长达一周时间才能被垃圾回收。因此，为了避免读取第 6 个值，您应始终滤除 5 个最新版本之外的所有内容。
在进行压缩并删除该数据之前，您需要支付过期数据的存储费用。
垃圾回收具有追溯性：设置新的垃圾回收政策后，在接下来的几天内，该政策将应用于表中的所有数据。如果新政策比以前的政策更严格，则旧数据会在后台工作开始执行时被删除，包括政策更改之前写入的数据。
如果您要确保标记为垃圾回收的数据被删除，可以查询表并将数据与预期结果进行比较。您还可以在 Google Cloud 控制台中监控表大小。如果表的大小没有缩减，则可能反映了垃圾回收政策未按预期工作，但请注意垃圾回收会延迟执行。
复制和垃圾回收
复制功能可能会对垃圾回收有以下几个方面影响。
基于版本的垃圾回收和 CPU 利用率
在使用复制功能的实例中，基于版本的垃圾回收中的删除会复制到实例中的所有集群，其方式与复制应用请求相同。如果您快速写入新单元，导致旧单元被标记为删除，那么当 Bigtable 删除过时单元并将这些删除复制到实例中的其他集群时，您可能会看到较高的 CPU 利用率。如果您将集群添加到包含使用基于版本的垃圾回收的表的实例，请准备好应对 CPU 利用率升高的情况。
另一方面，基于存在时间的垃圾回收不会提高复制实例中的 CPU 利用率。
更改基于版本的垃圾回收政策
您可以在复制表中修改列族的版本数上限。但是，如果您减少列族的版本数，则所有复制集群可能需要长达一周时间才能反映新的较小数量。因此，在读取数据时应始终使用过滤条件。
更改基于存在时间的垃圾回收政策
无论实例是否使用复制，您都可以增加或缩短垃圾回收政策中指定的保留时间。您还可以删除基于存在时间的垃圾回收政策。
缩短保留时间
如果您缩短基于年龄的政策中的保留期限，则所有集群可能需要长达一周的时间才能同步并使用新政策。
延长保留时间
在复制表中，您最多可以将垃圾回收政策的保留时长延长 90 天。
如果您延长列族的保留期限，请注意，您的集群可能超过一周的时间处于不同步状态。为了说明原因，请设想一个假设情况：您在一个双集群实例中有一个表，并将列族的保留期限从 30 天更改为 50 天：
- 将行键
ip#685的写入请求发送到集群 A，列族profile中列click-through的值为2023-01-02。数据将复制到集群 B。 - 31 天后，集群 A 发生垃圾回收，并且
click-through列中的值被识别为已过期和已删除。 - 您将更改
profile列族的垃圾回收政策，将 TTL 从 30 天增加到 50 天。 - 一天后，垃圾回收在集群 B 上运行。由于 TTL 为 50 天，因此值
2023-01-02会保留。 - 集群现在不同步并保持大约 20 天，直到集群 B 中存在的值（而不是集群 A 的值）最终被删除。