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

Cassandra警告

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

根据此文档How is data deleted，

Cassandra允许您为一个设置default_time_to_live属性整张桌子。标记有常规TTL的列和行将被处理如上所述;但是当记录超过表级TTL时， Cassandra立即删除它，没有墓碑或压实。

＆＃34;但是当记录超过表级TTL时，Cassandra会立即删除它，而不会进行墓碑或压缩。＆＃34;

为什么Cassandra对于墓碑仍然是WARN，因为我已经设置了default_time_to_live？

我使用某些CQL插入数据，而不使用TTL。

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

a similar question but it does not use default_time_to_live

似乎我可以将unchecked_tombstone_compaction设置为true？

另一个问题，我选择的数据与CLUSTERING ORDER的排序相同， Cassandra为什么会撞到这么多墓碑？

Answer 1

为什么Cassandra仍然为墓碑提供WARN，因为我已经设置了default_time_to_live？

TTL在Cassandra中的工作方式是，一旦记录过期，它就会被标记为墓碑（删除记录的过程相同）。因此，Cassandra不是在RDBMS世界中手动执行清除作业，而是允许您根据其TTL清理旧记录。但它仍然遵循与DELETE相同的过程，因此也就是墓碑。由于你的TTL值是＆＃39; 2592000＆＃39; （30天），表格中超过30天的任何内容都会过期（标记为墓碑 - 已删除）。

现在警告的原因是您的SELECT语句正在查找处于活动状态（未删除）的记录，并且警告消息是指在此过程中遇到多少个逻辑删除（已过期/已删除）记录。因此，在尝试提供9999个活着的记录时，该表沿途有X个墓碑。

由于TTL设置在表级别，因此该表中任何插入的记录都将具有30天的默认TTL。

以下是文档参考，以备您阅读更多内容。

在列创建超过TTL值后的秒数之后，TTL数据被视为已过期并包含在结果中。在读取路径上的下一次读取之后，过期数据用逻辑删除标记，但它最多保留gc_grace_seconds。

以上参考资料来自此link

似乎我可以将unchecked_tombstone_compaction设置为true？

它与你得到的警告毫无关系。您可以考虑减少gc_grace_seconds值（默认为10天）以更快地摆脱墓碑。但这个值有10天是有原因的。

请注意，DateTieriedCompactionStrategy是已删除的，一旦升级到3.11 Apache Cassandra或DSE 5.1.2，就会有TimeWindowCompactionStrategy在处理逻辑删除时做得更好。

在Cassandra

1 个答案: