在垃圾收集期间，yugabytedb如何保证快照一致？

Question

例如：

1. 有两个项目，k1和k2，时间t1。
2. 然后，读取事务(A)获得时间为t1的快照，事务(A)成功地用k1读取t1。
3. 同时，另一个事务(B)用time t2(t2>t1)编写t2。
4. yugabytedb以某种方式进行垃圾收集，因此带有t1的t1将被删除。
5. 如果transaction(A)用time t1读取t1，它将找不到时间小于t1的任何k2版本。

我不明白yugabytedb如何保持一致的快照。

我几乎搜索了yugabytedb的事务文档，但没有发现任何与垃圾收集有关的内容。

我已经看到了一些关于垃圾收集的谷歌扳手的描述，即保留旧版本的一个hour.But yugabytedb使用HLC而不是Truetime。

有人能介绍一下yugabytedb的垃圾收集机制吗？和扳手一样吗？

Answer 1

YugabyteDB用于一致性的一般机制是使用混合逻辑时钟(HLC)。参见此演示文稿：HLC。使用HLC，事务可以选择与其事务时间一致的行版本。我相信这已经是众所周知的了。

因为我们使用LSM树存储，所以不会覆盖任何数据。更新的行意味着同一行的另一个条目，具有不同的HLC时间戳。这样，当请求行时，事务可以选择与其HLC一致的行版本。

垃圾收集，别名清除旧的、非当前版本的行在主要压缩过程中发生。主要压缩是合并SST文件的过程。如果更改了大量数据，那么在很短的时间内就会发生重大的压缩，因此我们实现了一个参数/g频标记--时间戳_历史_保持时间间隔_sec，以保证最小的时间--一个更改仍然可用。

显然，如果更改量较低，则非当前版本可能会在很长一段时间内仍然可用。

压缩发生在rocksdb数据库中，这是表或辅助索引的每个tablet。