[
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.
This ticket is to discuss ideas and implementation details of such compaction
strategy.
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.
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
