[
https://issues.apache.org/jira/browse/CASSANDRA-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13621679#comment-13621679
]
Jonathan Ellis commented on CASSANDRA-5371:
-------------------------------------------
bq. I think you mean't to intersect the level0 sstables with the non-compacting
ones
Right. Fix pushed.
bq. the code only checks for STCS when a higher level is ready to be compacted
The idea is, we'd prefer to do normal LCS compaction on L0. So if the higher
levels are okay, we'll treat L0 the same as before. But if we do need to
compact a higher level, we'll first check and see if L0 is far enough behind
that we should do an STCS round there as a stop-gap.
bq. You should also add a check after that to make sure the non-compacting
level0 sstables are still > MAX_COMPACTING_L0
I think it's more correct as written -- basically, we're doing L0 out-of-turn,
since for max throughput we'd do the higher level next. So, we'll do L0 STCS
until it's under MCL0, then we'll go back to the higher levels until we catch
up and can actually apply leveling to L0.
> Perform size-tiered compactions in L0
> -------------------------------------
>
> Key: CASSANDRA-5371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5371
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 2.0
>
> Attachments: HybridCompactionStrategy.java
>
>
> If LCS gets behind, read performance deteriorates as we have to check bloom
> filters on man sstables in L0. For wide rows, this can mean having to seek
> for each one since the BF doesn't help us reject much.
> Performing size-tiered compaction in L0 will mitigate this until we can catch
> up on merging it into higher levels.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
