[
https://issues.apache.org/jira/browse/CASSANDRA-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081426#comment-13081426
]
Benjamin Coverston commented on CASSANDRA-1608:
-----------------------------------------------
It's a very simplistic trigger. You'll find it in the manifest code:
in Manifest.Promote:
{quote}
int newLevel = minimumLevel == maximumLevel ? maximumLevel + 1 :
maximumLevel;
newLevel = skipLevels(newLevel, added);
{quote}
This fixes the case where you have one large SSTable and you want to migrate
that SSTable to the new format. After a compaction it will find an empty level
for the new, non-overlapping set to fall into. Best case scenario for someone
migrating a lot of data with this code would be to do a major compaction
(tiered) followed by changing the compaction strategy to leveled.
Also, you should know that the synchronization code for this basically disables
concurrent compactions. I'm not sure if that's going to be an issue. To
re-enable concurrency in a sane manner I would need to introduce quite a bit of
complexity into the system. It's my hope that the work we're doing to improve
the concurrency of single compactions combined with the shorter duration of
each compaction in leveldb will make this a non-issue.
> Redesigned Compaction
> ---------------------
>
> Key: CASSANDRA-1608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1608
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Goffinet
> Assignee: Benjamin Coverston
> Attachments: 1608-v11.txt, 1608-v2.txt
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
