[jira] [Updated] (CASSANDRA-11106) Experiment with strategies for picking compaction candidates in LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-11106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-11106: - Component/s: Compaction > Experiment with strategies for picking compaction candidates in LCS > --- > > Key: CASSANDRA-11106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11106 > Project: Cassandra > Issue Type: Improvement > Components: Compaction >Reporter: Marcus Eriksson >Assignee: Dikang Gu >Priority: Major > Labels: lcs > Fix For: 4.x > > > Ideas taken here: http://rocksdb.org/blog/2921/compaction_pri/ > Current strategy in LCS is that we keep track of the token that was last > compacted and then we start a compaction with the sstable containing the next > token (kOldestSmallestSeqFirst in the blog post above) > The rocksdb blog post above introduces a few ideas how this could be improved: > * pick the 'coldest' sstable (sstable with the oldest max timestamp) - we > want to keep the hot data (recently updated) in the lower levels to avoid > write amplification > * pick the sstable with the highest tombstone ratio, we want to get > tombstones to the top level as quickly as possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11106) Experiment with strategies for picking compaction candidates in LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-11106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-11106: Fix Version/s: 3.x > Experiment with strategies for picking compaction candidates in LCS > --- > > Key: CASSANDRA-11106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11106 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson > Labels: lcs > Fix For: 3.x > > > Ideas taken here: http://rocksdb.org/blog/2921/compaction_pri/ > Current strategy in LCS is that we keep track of the token that was last > compacted and then we start a compaction with the sstable containing the next > token (kOldestSmallestSeqFirst in the blog post above) > The rocksdb blog post above introduces a few ideas how this could be improved: > * pick the 'coldest' sstable (sstable with the oldest max timestamp) - we > want to keep the hot data (recently updated) in the lower levels to avoid > write amplification > * pick the sstable with the highest tombstone ratio, we want to get > tombstones to the top level as quickly as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11106) Experiment with strategies for picking compaction candidates in LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-11106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Deng updated CASSANDRA-11106: - Labels: lcs (was: ) > Experiment with strategies for picking compaction candidates in LCS > --- > > Key: CASSANDRA-11106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11106 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson > Labels: lcs > > Ideas taken here: http://rocksdb.org/blog/2921/compaction_pri/ > Current strategy in LCS is that we keep track of the token that was last > compacted and then we start a compaction with the sstable containing the next > token (kOldestSmallestSeqFirst in the blog post above) > The rocksdb blog post above introduces a few ideas how this could be improved: > * pick the 'coldest' sstable (sstable with the oldest max timestamp) - we > want to keep the hot data (recently updated) in the lower levels to avoid > write amplification > * pick the sstable with the highest tombstone ratio, we want to get > tombstones to the top level as quickly as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
