[
https://issues.apache.org/jira/browse/CASSANDRA-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14028820#comment-14028820
]
sankalp kohli edited comment on CASSANDRA-6621 at 6/12/14 4:49 AM:
-------------------------------------------------------------------
"What if we detect that, and include a couple of those high level sstables in
lower lever compactions until the higher level is empty or starts doing real
compactions?"
Yes we can keep doing that till last level is the only level which is not full.
To minimize this, like I said we can do this:
"Stream stables from the source by sorting them by level which will cause
streaming of stables in following order L1 to Lx and then finally L0."
I think it will help.
was (Author: kohlisankalp):
"What if we detect that, and include a couple of those high level sstables in
lower lever compactions until the higher level is empty or starts doing real
compactions?"
Yes we can keep doing that till last level is the only level which is not full.
To minimize this, like I said we can do this:
"Stream stables from the source by sorting them by level which will cause
streaming of stables in following order L1 to Lx and then finally L0."
Sounds good?
> STCS fallback is not optimal when bootstrapping
> -----------------------------------------------
>
> Key: CASSANDRA-6621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6621
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Bartłomiej Romański
> Priority: Minor
>
> The initial discussion started in (closed) CASSANDRA-5371. I've rewritten my
> last comment here...
> After streaming (e.g. during boostrap) Cassandra places all sstables at L0.
> At the end of the process we end up with huge number of sstables at the
> lowest level.
> Currently, Cassandra falls back to STCS until the number of sstables at L0
> reaches the reasonable level (32 or something).
> I'm not sure if falling back to STCS is the best way to handle this
> particular situation. I've read the comment in the code and I'm aware why it
> is a good thing to do if we have to many sstables at L0 as a result of too
> many random inserts. We have a lot of sstables, each of them covers the whole
> ring, there's simply no better option.
> However, after the bootstrap situation looks a bit different. The loaded
> sstables already have very small ranges! We just have to tidy up a bit and
> everything should be OK. STCS ignores that completely and after a while we
> have a bit less sstables but each of them covers the whole ring instead of
> just a small part. I believe that in that case letting LCS do the job is a
> better option that allowing STCS mix everything up before.
> Is there a way to disable STCS fallback? I'd like to test that scenario in
> practice during our next bootstrap...
> Does Cassandra really have to put streamed sstables at L0? The only thing we
> have to assure is that sstables at any given level do not overlap. If we
> stream different regions from different nodes how can we get any overlaps?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
