带有 TTL 的 Cassandra 墓碑答案

【问题标题】：Cassandra tombstones with TTL带有 TTL 的 Cassandra 墓碑
【发布时间】：2019-07-09 17:07:38
【问题描述】：

我使用 cassandra 已经有一段时间了 (DSE)，我试图理解一些不太清楚的东西。我们为此插图运行 DSE 5.1.9。它是一个单节点集群（如果您有一个多节点集群，请确保 RF=nodeCount 以使事情变得更容易）。

这是一个非常简单的例子：创建以下简单表：

CREATE TABLE mytable (
    status text,
    process_on_date_time int,
    PRIMARY KEY (status, process_on_date_time)
) WITH CLUSTERING ORDER BY (process_on_date_time ASC)
AND gc_grace_seconds = 60

我有一段代码可以一次插入 5k 条记录，总共最多 200k 条记录，TTL 为 300 秒。状态总是“待定”，process_on_date_time 是一个以 1 递增的计数器，从 1 开始（所有唯一记录 - 基本上是 1 - 200k）。

我运行代码，然后在完成后将内存表刷新到磁盘。只创建了一个 sstable。在此之后，没有压缩，没有修复，没有其他运行会创建或更改 sstable 配置。

sstable 转储后，我进入 cqlsh，打开跟踪，将一致性设置为 LOCAL_ONE 并关闭分页。然后我重复运行：

SELECT * from mytable where status = 'pending' and process_on_date_time <= 300000;

有趣的是我看到了这样的东西（为了便于阅读，删掉了一些文字）：

Run X) Read 31433 live rows and 85384 tombstone cells (31k rows returned to my screen) 
Run X+1) Read 0 live rows and 76376 tombstone cells (0 rows returned to my screen - all rows expired at this point) 
Run X+2) Read 0 live rows and 60429 tombstone cells 
Run X+3) Read 0 live rows and 55894 tombstone cells 
... 
Run X+X) Read 0 live rows and 0 tombstone cells

发生了什么事？ sstable 没有改变（显然因为它是不可变的），没有其他任何插入、刷新等。为什么墓碑计数会减少直到它为 0？是什么导致了这种行为？

我希望看到每次运行：100k 墓碑被读取，查询中止，因为所有 TTL 都在单个 sstable 中过期。

【问题讨论】：

在尝试第一次选择调用之前，您是否尝试过 SSTabledump 来实际检查 SSTable 中的内容？这样你就可以知道它到底有多少个实际的墓碑。

标签： cassandra datastax-enterprise

【解决方案1】：

对于其他可能对此答案感到好奇的人，我用 Datastax 开了一张票，这是他们提到的：

在墓碑通过 gc_grace_seconds 后，它们将在结果集，因为它们在过去之后被过滤掉了观点。所以你的假设是正确的，唯一的方法是要发布的墓碑警告将是数据超过他们的 ttl 但仍在 gc_grace 内。

而且由于它们被忽略/过滤掉，它们不会有任何有害的对系统的影响，因为就像你说的那样，它们被跳过了。

所以这意味着如果 TTL 过期，但在 GC 宽限秒内，则在查询时它们将被计为墓碑。如果 TTL 过期并且 GC 宽限秒也过期，则它们不会被计为墓碑（跳过）。系统仍然必须“清除”过期的 TTL 记录，但除了处理时间之外，对查询没有“害处”。我发现这很有趣，因为我在任何地方都没有看到这个记录。

认为其他人可能对此信息感兴趣，如果他们的经历不同，可以添加。

【讨论】：