[jira] Commented: (CASSANDRA-1608) Redesigned Compaction

["Oleg Anastasyev (JIRA)" <ji...@apache.org>]

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

Oleg Anastasyev commented on CASSANDRA-1608:
--------------------------------------------

I propose to limit size of sstables not directly in megabytes, but by partitioning them by token ranges, like normal cassandra ring is implemented. This way, data are partitioned on cassandra cluster by token ranges across nodes, and , additionally on each node it is partitioned into several subranges of the node's token range. 
Each of token subranges is tracked separatedly and is stored in separate memtable and sstable set. Rows from different subranges are never stored in the same memtable and sstable. Compactions and other operations are running on sstables from exactly 1 subrange. 

This way complexities with rows tracking, prioretization, etc of fixed size sstables are eliminated, I believe and we have smaller sstables (well, not exactly at 500Mb limit each, but this is not the target, I think) and lighter compactions.

> Redesigned Compaction
> ---------------------
>
>                 Key: CASSANDRA-1608
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1608
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Chris Goffinet
>             Fix For: 0.7.1
>
>
> After seeing the I/O issues in CASSANDRA-1470, I've been doing some more thinking on this subject that I wanted to lay out.
> I propose we redo the concept of how compaction works in Cassandra. At the moment, compaction is kicked off based on a write access pattern, not read access pattern. In most cases, you want the opposite. You want to be able to track how well each SSTable is performing in the system. If we were to keep statistics in-memory of each SSTable, prioritize them based on most accessed, and bloom filter hit/miss ratios, we could intelligently group sstables that are being read most often and schedule them for compaction. We could also schedule lower priority maintenance on SSTable's not often accessed.
> I also propose we limit the size of each SSTable to a fix sized, that gives us the ability to  better utilize our bloom filters in a predictable manner. At the moment after a certain size, the bloom filters become less reliable. This would also allow us to group data most accessed. Currently the size of an SSTable can grow to a point where large portions of the data might not actually be accessed as often.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.