[
https://issues.apache.org/jira/browse/CASSANDRA-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13622068#comment-13622068
]
T Jake Luciani commented on CASSANDRA-5371:
-------------------------------------------
[~jbellis] let me run some tests but the code looks good now.
[~slebresne]
bq. do we have performance numbers for this (including, not only on SSD tests)?
We only have SSD and I think LCS only ever makes sense on SSD. If we want to
support HDD then I agree this is def more IO overall. The performance numbers
for our use case went from all read timeouts using LCS to reads rarely timing
out with the original patch. The stress tool doesn't have a wide row scenario
so it's hard to simulate out of the box.
bq. doesn't that mean you have bigger problems (and/or that you should just use
STSC)
STCS isn't viable for the LCS use cases. I don't see how having this (on SSD)
would not help all LCS use cases since LCS is for wide row or heavy updates.
The point of this is to avoid the situation where all sstables in L0 contain a
portion of the row which requires reading them all. One thing to keep in mind
is if you do have a wide row and you end up with a STCS compacted row of 10MB
and LCS has a 5MB limit you still end up with a 10MB sstable with a single row
in it so the higher levels do benefit from STCS in this case.
> 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
