[jira] [Resolved] (CASSANDRA-8866) PartitionedCompactionStrategy

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

     [ 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)