Cassandra 中的 DateTieredCompactionStrategy 子属性

Question

对 Cassandra 中的 DateTieredCompactionStrategy 子属性有一些疑问

1. 博客http://www.datastax.com/dev/blog/datetieredcompactionstrategy 说： Base_time_seconds：“这是第一个窗口的大小，默认为 3600 秒（1 小时）。其余窗口的大小将是 min_threshold（默认 4）乘以前一个窗口的大小。” 默认值为 3600，即 base_time_seconds 为 1 小时，这是否意味着第一次压缩在第 1 小时触发，接下来在 4、16、64 小时等等？

2. max_window_size_seconds：默认 1 天。这是否意味着我的压缩每天至少运行一次？

3. tombstone_compaction_interval：默认 10 天。 如果我的 sstable 已经 7 天了，但是由于 ttl 1 天和 1 天的 GC_grace_sec 而充满了过期数据。这是否意味着我的 sstables 仍然没有被删除？

tombstone_compaction_interval 是否优先于 ttl 和 GC_grace_sec

4. min_threshold：当compaction运行时，sstables的no是

Answer 1

1. 否 - DTCS 在其中一个窗口（1h、4h、..）中找到 sstable，如果它认为需要将它们压缩在一起（第一个窗口的 iirc 必须大于 min_threshold，其余 2或更多），它会的。
2. 没有。压缩的数量仅取决于刷新/流式传输的 sstable 的数量。最大窗口大小只是为了确保我们不会在引导/流式传输等时获得巨大的旧窗口。
3. 不，使用 DTCS，您不应该触及 tombstone_compaction_interval - 整个想法是，一旦整个 sstable 过期，整个内容将自动删​​除而无需压缩。
4. 正确，但它是每个窗口的，因此您可以使用 DTCS 在单独的窗口中拥有 100 个 sstable

请注意，DTCS 已被弃用，您应该真正改用 TWCS。如果您使用 cassandra https://github.com/jeffjirsa/twcshttps://issues.apache.org/jira/browse/CASSANDRA-9666