[
https://issues.apache.org/jira/browse/CASSANDRA-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13622038#comment-13622038
]
Sylvain Lebresne commented on CASSANDRA-5371:
---------------------------------------------
For my own curiosity, do we have performance numbers for this (including, not
only on SSD tests)?
A priori, I'm not fully sold on this being always a win (or even most of the
time of "L0 is being"). That is, I understand the reasoning that lots of
SSTables in L0 is bad for reads, but at the same time, if you compact STCS
things in L0, a lot of the work you've done you will redo when you compact your
now bigger L0 sstable against L1. I.e. those STCS compactions don't help you
make progress as far as leveling is concerned, so it seems like it waste work
overall. Besides, in theory, our LCS is supposed to be able to compact large
amount of L0 sstables into L1 to help with the "I'm behind on L0 but it's just
a pike in load". Now I guess if you've pushed a lot of data in L1 and get
behind again in L0, then it's not fun because all of L1 need to be including in
L0 compaction. But if you are constantly behind, doesn't that mean you have
bigger problems (and/or that you should just use STSC)?
Basically I wonder if there won't be a number of scenario where because you get
a bit behind on L0 once, then the I/O you "waste" doing STSC in L0 will help
you get even more and more behind on your leveling and you'd end up doing
mostly STSC, while letting LCS do its job would have been fine overall.
That is, I'm happy with this if that makes things clearly better in practice
more often than not, it's just that intellectually it's not obvious to me that
it's the case (note that I'm not saying that it's obvious it's a bad idea
either).
> 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
