You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2013/01/26 00:11:13 UTC

[jira] [Commented] (CASSANDRA-3678) New Pluggable Compaction to handle Capped Rows / Super Columns

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

Jonathan Ellis commented on CASSANDRA-3678:
-------------------------------------------

addressing in CASSANDRA-3929
                
> New Pluggable Compaction to handle Capped Rows / Super Columns
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-3678
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3678
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Contrib, Core
>         Environment: ALL
>            Reporter: Praveen Baratam
>              Labels: features
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> Now that Pluggable Compaction is released, its feasible to implement a CompactionStrategy that handles Capped (Limited in size) Rows or SuperColumns in a ColumnFamily. This feature was requested many times on mailing lists by many people including me.
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Use-Case-scenario-Keeping-a-window-of-data-online-analytics-td4694907.html
> The above thread was quoted in Cassandra - Use Cases too.
> Reading and interpreting many conversations over this issue, I could infer that it was discussed in two flavors.
> 1. Enforcing Max Columns per Row/SC 
> 2. Sliding Time Window
> Many a times MEMTABLE/SSTABLE approach of Cassandra is quoted as a limiting factor for an amicable implementation. In  my perspective the above mentioned SSTABLE approach could mean some trade-offs and clever engineering but its still doable.
> This feature is not intended to offer a drop-in replacement for specialized tools like RRDTool, jRobin, etc. but to decrease the overhead of retro fitting such functionality into CASSANDRA and finding an approach that achieves the principal purpose of discarding obsolete data and stretching only as far as necessary.
> This ticket is to discuss ideas and implementation details of such compaction strategy.

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