[jira] [Commented] (CASSANDRA-5561) Compaction strategy that minimizes re-compaction of old/frozen data

["Edward Capriolo (JIRA)" <ji...@apache.org>]

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

Edward Capriolo commented on CASSANDRA-5561:
--------------------------------------------

One simple way to do this would be to specific a range in seconds like a week. A more complex but possibly better way would be having max number of acceptable sstables say 100. and we could calculate the distribution of range of time in an sstable and size. All the old weeks will likely have little or no data, they might have some bloom filter false positives so they might persist for longer then the target ttl age but they will get lumped together in the 'old stuff' sstable group. Normally the fixed sstable count and the distribution rules should make one table a week. 


                
> Compaction strategy that minimizes re-compaction of old/frozen data
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-5561
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5561
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.2.3
>            Reporter: Tupshin Harper
>             Fix For: 2.0.1
>
>
> Neither LCS nor STCS are good for data that becomes immutable over time. The most obvious case is for time-series data where the application can guarantee that out-of-order delivery (to Cassandra) of events can't take place more than N minutes/seconds/hours/days have elapsed after the real (wall time).
> There are various approaches that could involve paying attention to the row keys (if they include a time component) and/or the column name (if they are TimeUUID or Integer based and are inherently time-ordered), but it might be sufficient to just look at the timestamp of the columns themselves.
> A possible approach:
> 1) Define an optional max-out-of-order window on a per-CF basis.
> 2) Use normal (LCS or STCS) compaction strategy for any SSTables that include any columns younger than max-out-of-order-delivery).
> 3) Use alternate compaction strategy (will call it TWCS time window compaction strategy for now) for any SSTables that only contain columns older than max-out-of-order-delivery.
> 4) TWCS will only compact sstables containing data older than max-out-of-order-delivery.
> 5) TWCS will only perform compaction to reduce row fragmentation (if there is any by the time it gets to TWCS or to reduce the number of small sstables.
> 6) To minimize re-compaction in TWCS, it should aggresively try to compact as many small sstables as possible into one large sstable that would never have to get recompacted. 
> In the case of large datasets (e.g. 5TB per node) with LCS, there would be on the order of seven levels, and hence seven separate writes of the same data over time. With this approach, it should be possible to get about 3 compactions per column (2 in original compaction and one more once hitting TWCS) in most cases, cutting the write workload by a factor of two or more for high volume time-series applications.
> Note that the only workaround I can currently suggest to minimize compaction for these workloads is to programatically shard your data across time-window ranges (e.g. new CF per week), but that pushes unnecessary writing and querying logic out to the user and is not as convenient nor flexible.
> Also note that I am not convinced that the approach I've suggested above is the best/most general way to solve the problem, but it does appear to be a relatively easy one to implement.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira