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

Jonathan Ellis resolved CASSANDRA-8866.
---------------------------------------
    Resolution: Duplicate
      Reviewer:   (was: Carl Yeksigian)

... okay, reading the previous comment there isn't actually one file per 
partition (in the normal Cassandra terminology of partition).  There's one file 
per token range.

So really this is a more limited implementation of CASSANDRA-6696 which is no 
doubt what Aleksey meant.  This is basically what you'd get with a "compact 
everything, all the time" strategy on top of 6696, which is going to do a lot 
worse from a write amplification standpoint than STCS or even LCS.  So I'm 
going to close this as a duplicate.

> PartitionedCompactionStrategy
> -----------------------------
>
>                 Key: CASSANDRA-8866
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8866
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Takenori Sato
>         Attachments: cassandra-2.0-8866.txt
>
>
> PartitionedCompactionStrategy is a new compaction strategy with the following 
> goals in mind:
> * Column tombstone removal effectiveness
> * Read performance
> As the name suggests, PartitionedCompactionStrategy actively splits 
> un-partitioned sstables(newly flushed, imported, compaction strategy switch) 
> into partitions by IPartitioner. The number of nodes will be configurable.
> Then, PartitionedCompactionStrategy finds an interesting partition at 
> compaction based on the followings:
> - the number of sstables
> - the ratio of droppable tombstones
> - read hotness
> You may think this design looks similar to SizeTieredCompactionStrategy and 
> LeveledCompactionStrategy, but the big difference is that a compaction by 
> PartitionedCompactionStrategy is based on rows(a partitions). And this allows 
> more effective column tombstone removal, and better read performance.
> Also note that this will not require any changes to the other components. So 
> this is expected to be a purely pluggable compaction strategy.
> A possible implementation of 
> _PertitionedCompactionStrategy#getNextBackgroundTask()_ is as follows:
> # find un-partitioned sstables
> # split un-partitioned sstables into partitiones
> # group all the sstables into partitions
> # find an interesting partition
> #* the number of sstables
> #* the number of droppable tombstones
> #* hotness
> # create a compaction task for the interesting bucket if found



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to