[ 
https://issues.apache.org/jira/browse/CASSANDRA-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14144912#comment-14144912
 ] 

Carl Yeksigian commented on CASSANDRA-7409:
-------------------------------------------

This was the original purpose of the same level compaction; it was supposed to 
place the results of the compaction into the same level. It seems that I broke 
it at some point, but with that correction, it should behave correctly for the 
last part.

For the earlier, it makes sense to try to include the sstables which overlap 
the least into an uplevel compaction. This will keep the keys which are being 
written to a lot in a level which allows for overlapping.

I'm happy to change the overlap estimator, assuming we can figure out which one 
we'd like to say is going to be our estimator going forward. If it's still 
going to be experimental, I think I'd rather just leave it as a really rough 
estimator of the overlap, and change it afterwards.

There are two measures against vanilla LCS that we want to test.

- L0 Compaction
  No reads, no writes. Take sstables and dump into L0.
  Metric: Time to 0 compactions remaining.

- Heavy write
  Heavy writes (such that LCS is overwhelmed), some reads
  Metric: read 0.99

I expect that L0 compaction times should be similar between LCS w/ STCS and 
OCS, with OCS being slightly slower. Under the heavy write scenario, however, 
there should be a large benefit to using OCS.


> Allow multiple overlapping sstables in L1
> -----------------------------------------
>
>                 Key: CASSANDRA-7409
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7409
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Carl Yeksigian
>            Assignee: Carl Yeksigian
>              Labels: compaction
>             Fix For: 3.0
>
>
> Currently, when a normal L0 compaction takes place (not STCS), we take up to 
> MAX_COMPACTING_L0 L0 sstables and all of the overlapping L1 sstables and 
> compact them together. If we didn't have to deal with the overlapping L1 
> tables, we could compact a higher number of L0 sstables together into a set 
> of non-overlapping L1 sstables.
> This could be done by delaying the invariant that L1 has no overlapping 
> sstables. Going from L1 to L2, we would be compacting fewer sstables together 
> which overlap.
> When reading, we will not have the same one sstable per level (except L0) 
> guarantee, but this can be bounded (once we have too many sets of sstables, 
> either compact them back into the same level, or compact them up to the next 
> level).
> This could be generalized to allow any level to be the maximum for this 
> overlapping strategy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to