[
https://issues.apache.org/jira/browse/CASSANDRA-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13622109#comment-13622109
]
Sylvain Lebresne commented on CASSANDRA-5371:
---------------------------------------------
bq. The stress tool doesn't have a wide row scenario so it's hard to simulate
out of the box
Agreed, and that's definitively lacking. I believe there is a few knobs that
allow to do wideish rows, but that's probably not very realistic.
{quote}
I think LCS only ever makes sense on SSD
since LCS is for wide row or heavy updates
{quote}
I'm not sure I agree. Maybe there is some truth to it in our current
implementation, but that would then be more of a quirk of the implementation
that the goal. Typically, I'm not really sure why only wide rows would benefit
it. There is certainly nothing in theory that makes it so. As for "it's for
heavy updates only", I think that LCS has a number of nice properties (like
avoiding huge files that require half of you disk in free space) that are nice
even if you have a moderate to low update rate (and in that case you can
definitively afford LCS on HDD). More concretely, I'm pretty sure we have tons
on users on LCS on HDD.
Anyway, all this to say that I don't necessary agree on optimizing LCS for
heavy writes + wide rows + SSD *if* that's done at the expense of all other
type of workload (and I'm not saying that's what this patch is doing, just that
discarding other type of workload as unimportant is not ok imo).
bq. LCS has a 5MB limit you still end up with a 10MB sstable with a single row
If having 10MB sstables being split due to row too wide is a problem, then you
should either not use LCS or pick a 10MB limit for LCS, not 5MB.
Anyway, I'm not vetoing this or anything like this. Just trying to get a better
understanding of why this is a good thing to do in general.
> 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
