cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Praveen Baratam (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-3678) New Pluggable Compaction to handle Capped Rows / Super Columns
Date Wed, 28 Dec 2011 07:10:30 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Praveen Baratam updated CASSANDRA-3678:
---------------------------------------

    Description: 
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.

  was:
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.

    
> 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 message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message