cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5371) Perform size-tiered compactions in L0
Date Thu, 04 Apr 2013 12:53:16 GMT

    [ 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

Mime
View raw message