[
https://issues.apache.org/jira/browse/CASSANDRA-9130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14615546#comment-14615546
]
Jonathan Shook commented on CASSANDRA-9130:
-------------------------------------------
I'm not particularly concerned about the corner cases for lots of sstables, but
it does need to be documented better. We do not yet have tools to manage
re-compacting DTCS past max_sstable_age_days. Even if we did, it would not be
an automatic win in every case. The operational trade-offs that come with
different max_sstable_age_days are simply too stark to avoid. I still believe
that 365 is way too high. Studying the total bytes compacted over different
DTCS settings and ingest rates can show the IO load. 365 is way beyond the
point at which you start paying for more compaction than you need in most
systems.
I do agree, though about the boundary condition. We should have a safety in
place to avoid max_sstable_age_days > table TTL until we can verify that a
TTL-specific compaction pass will occur as needed.
This might be a concern as well for per-write TTLs.
[~jjirsa]
Is there a way that you would like to see the interplay between TTLs and
max_sstable_age_days handled? Is there a solution which you would consider safe?
> reduct default dtcs max_sstable_age
> -----------------------------------
>
> Key: CASSANDRA-9130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9130
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Marcus Eriksson
> Priority: Minor
> Fix For: 3.x, 2.1.x, 2.0.x
>
>
> Now that CASSANDRA-9056 is fixed it should be safe to reduce the default age
> and increase performance correspondingly. [~jshook] suggests that two weeks
> may be appropriate, or we could make it dynamic based on gcgs (since that's
> the window past which we should expect repair to not introduce fragmentation
> anymore).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
