cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Jirsa (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10280) Make DTCS work well with old data
Date Tue, 22 Sep 2015 16:33:04 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902915#comment-14902915
] 

Jeff Jirsa commented on CASSANDRA-10280:
----------------------------------------

[~jshook] I would expect it not to affect tombstone compaction scheduling, based on my reading
and familiarity with the code. 

Now for ponies/bikeshed: 

I want to - respectfully and humbly - suggest that IF we're breaking backwards compatibility
(and I'll state that I believe it's necessary to kill {{max_sstable_age_days}} for DTCS to
be viable in the real world), that CASSANDRA-9666 accomplishes this same basic behavior in
a very similar manner in a much more predictable and easier-to-operate manner, without the
weird arithmetic of the Target class. 

I realize that wholesale swapping of strategies is not easy, but we're already breaking backward
compatibility here. This patch combined with CASSANDRA-10276 certainly fix a lot of problems
with DTCS, so I'm in favor of them (as a heavy user of DTCS), but I'm still convinced that
9666 is more predictable and easier to reason about than DTCS+10280+10276




> 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)

Mime
View raw message