也被回答Cassandra允许您为整个表设置default_time_to_live属性。标记有常规TTL的列和行如上所述进行处理;但是当记录超过表级TTL时, Cassandra会立即将其删除,而不会引起墓碑或压缩。
如果表上具有default_time_to_live,则超过该时间限制的行将被立即删除,而无需写入逻辑删除。
并在LastPickle的帖子About deletes and tombstones
中进行了评论要探索的另一个线索是,如果合适的话,可以使用TTL作为默认值。在表级别使用'default_time_to_live'设置的TTL在C * 3.0 + 中完全不应生成任何逻辑删除。没有经过我的测试,但是我读到了这件事。
我使用LeveledCompactionStrategy
做了我可以想象的最简单的测试:
CREATE KEYSPACE IF NOT EXISTS temp WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'};
CREATE TABLE IF NOT EXISTS temp.test_ttl (
key text,
value text,
PRIMARY KEY (key)
) WITH compaction = { 'class': 'LeveledCompactionStrategy'}
AND default_time_to_live = 180;
INSERT INTO temp.test_ttl (key,value) VALUES ('k1','v1');
nodetool flush temp
sstabledump mc-1-big-Data.db
sstabledump mc-1-big-Data.db
nodetool compact temp
sstabledump mc-2-big-Data.db
该测试是使用apache cassandra 3.0.13
进行的从示例中,我得出结论,default_time_to_live
至少在3.0.13版本中不需要逻辑删除,这是不正确的。
但是,这是一个非常简单的测试,因此我将强制使用nodetool compact
进行重大压缩,因此我可能不会重新创建default_time_to_live魔术开始起作用的场景。
但是C *如何在没有逻辑删除的情况下删除?为什么这与每个插入使用TTL的场景不同?
答案 0 :(得分:2)
当您在我们的博客(The Last Pickle Blog)上回答此问题时,您被提到的那篇文档愚弄了我。即使我写这个东西是“探索”的,甚至说我没有明确尝试,我可能也回答得太快了。
要探索的另一个线索是,如果出现以下情况,则将TTL用作默认值 很合适在表级别设置的TTL 'default_time_to_live'完全不应该生成任何逻辑删除 C * 3.0 + 。没有经过我的测试,但是我读到了这件事。
所以我上面的句子是错误的。基本上,默认值可以在查询级别由TTL覆盖,并且我不知道Cassandra如何在没有逻辑删除的情况下进行处理。
从示例中我得出结论,那是不正确的
default_time_to_live
至少在版本中不需要墓碑 3.0.13。
此外,很高兴看到您不相信我或Datastax文档,而是自己尝试了。绝对是正确的方法。
但是C *如何在没有逻辑删除的情况下删除?为什么这应该是一个 每个插入使用TTL的情况是否不同?
是的,完全是这样
C * heers。
Alain Rodriguez-@arodream-alain@thelastpickle.com 法国/西班牙
最后的泡菜-Apache Cassandra Consulting http://www.thelastpickle.com
答案 1 :(得分:1)
AFAIK逻辑删除记录与TTL过期的记录之间没有太大区别。在您的情况下,将主要压缩转换为TTL过期记录强制到逻辑删除,但由于gc_grace_seconds而未被清除。根据此presentation,墓碑/ ttl-expired-records消失了:
因此从技术上讲,墓碑/ ttl可能会在gc_grace之后消失,但不能保证。