使用默认的TTL列，但Cassandra中的逻辑删除数量很多

Question

我使用Cassandra 3.0.12。

我有一个具有以下架构的cassandra Column Family或CQL表：

CREATE TABLE win30 (
    cust_id text,
    tid timeuuid,
    info text,
    PRIMARY KEY (cust_id , tid )
) WITH CLUSTERING ORDER BY (tid DESC) 
and compaction = {'class': 'DateTieredCompactionStrategy', 'max_sstable_age_days': 31 };

alter table win30 with default_time_to_live = '2592000';

我已经为整个表格设置了default_time_to_live属性，但是当我查询表格时，

select * from win30 order by tid desc limit 9999

卡桑德拉警告说

Read xx live rows and xxxx tombstone for query  xxxxxx (see tombstone_warn_threshold).

根据此文档， 如何删除数据 ，

Cassandra允许您为整个表设置default_time_to_live属性。 标记有常规TTL的列和行如上所述进行处理； 但是当记录超过表级TTL时，Cassandra会立即删除它，而不会导致逻辑删除或压缩。

“但是，当记录超过表级别的TTL时，Cassandra会立即删除它，而不会引起逻辑删除或压缩。”

为什么自设置了default_time_to_live以来，Cassandra仍对墓碑保持警惕？

我使用类似CQL的方式插入数据，而不使用TTL。

insert into win30 (cust_id, tid, info ) values ('123', now(), 'sometext'); 

一个类似的问题，但它不使用default_time_to_live

看来我可以将unchecked_tombstone_compaction设置为true吗？

另一个问题是，我选择的数据顺序与“聚类顺序”相同，为什么卡桑德拉（Cassandra）碰到那么多墓碑？

Answer 1

为什么自设置了default_time_to_live以来，Cassandra仍对墓碑保持警惕？

TTL在Cassandra中的工作方式是，一旦记录过期，将其标记为逻辑删除（与删除记录的过程相同）。 因此，Cassandra无需在RDBMS世界中手动执行清除工作，而是使您能够根据其TTL清除旧记录。 但是它仍然遵循与DELETE相同的过程，因此也遵循了逻辑删除。 由于您的TTL值为“ 2592000”（30天），因此表中超过30天的所有内容都会过期（标记为逻辑删除-已删除）。

现在，发出警告的原因是您的SELECT语句正在寻找活动（未删除）的记录，并且警告消息是在该过程中遇到了多少个逻辑删除（过期/删除）的记录。 因此，当尝试提供9999个活动记录时，表在此过程中命中了X个逻辑删除。

由于TTL是在表级别设置的，因此此表中插入的任何记录的默认TTL均为30天。

如果您想了解更多信息，这是文档参考。

自创建列以来的秒数超过TTL值后，TTL数据将被视为已过期并包含在结果中。 在读取路径上的下一次读取之后，已过期的数据将用墓碑标记，但是最多保留gc_grace_seconds。

以上参考来自此链接

看来我可以将unchecked_tombstone_compaction设置为true吗？

它与您得到的警告无关。 您可以考虑减少gc_grace_seconds值（默认为10天）以更快地清除逻辑删除。 但是有一个理由将此值设置为10天。

请注意，DateTieriedCompactionStrategy已创建，一旦您升级到3.11 Apache Cassandra或DSE 5.1.2，便有了TimeWindowCompactionStrategy，它在处理墓碑方面做得更好。