[
https://issues.apache.org/jira/browse/CASSANDRA-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14901028#comment-14901028
]
Jonathan Shook commented on CASSANDRA-10280:
--------------------------------------------
I've read the patch and the comments. Deprecating max_sstable_age_days in favor
of the max window size is a good simplification. It also does what I originally
had hoped max_sstable_age_days would do. So +1 on all of that.
Just to make sure, can we identify whether or not this might affect tombstone
compaction scheduling? As in, could it cause tombstone compactions that would
otherwise happen to not?
> Make DTCS work well with old data
> ---------------------------------
>
> Key: CASSANDRA-10280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10280
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Marcus Eriksson
> Assignee: Marcus Eriksson
> Fix For: 3.x, 2.1.x, 2.2.x
>
>
> Operational tasks become incredibly expensive if you keep around a long
> timespan of data with DTCS - with default settings and 1 year of data, the
> oldest window covers about 180 days. Bootstrapping a node with vnodes with
> this data layout will force cassandra to compact very many sstables in this
> window.
> We should probably put a cap on how big the biggest windows can get. We could
> probably default this to something sane based on max_sstable_age (ie, say we
> can reasonably handle 1000 sstables per node, then we can calculate how big
> the windows should be to allow that)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
