Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 28 Dec 2011 07:08:30 +0000 (UTC)
From: "Praveen Baratam (Created) (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1571677737.48013.1325056110813.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (CASSANDRA-3678) New Pluggable Compaction to
 handle Capped Rows / Super Columns
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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


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