Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 10 Jun 2014 21:13:03 +0000 (UTC)
From: "sankalp kohli (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12691271.1390753410946.104519.1402434783642@arcas>
In-Reply-To: <JIRA.12691271.1390753410946@arcas>
References: <JIRA.12691271.1390753410946@arcas>
Subject: [jira] [Commented] (CASSANDRA-6621) STCS fallback is not optimal
 when bootstrapping
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-6621?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14027029#comment-14027029 ]=20

sankalp kohli commented on CASSANDRA-6621:
------------------------------------------

"If we stream different regions from different nodes how can we get any ove=
rlaps?"
If a node from which it is streaming has the same row in two stable in diff=
erent levels, it will come in as 2 stables. The only place we can put it is=
 L0.=20
We might want to also stream the stable level and can put stables coming fr=
om same level in one level on the bootstrapping node.  The problem with thi=
s will be that we might end up with very few stable in higher levels violat=
ing the constrain that only last level can be less than limit.=20


> 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=C5=82omiej Roma=C5=84ski
>            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 L=
0. At the end of the process we end up with huge number of sstables at the =
lowest level.=20
> Currently, Cassandra falls back to STCS until the number of sstables at L=
0 reaches the reasonable level (32 or something).
> I'm not sure if falling back to STCS is the best way to handle this parti=
cular 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 man=
y 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 i=
n 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 w=
e stream different regions from different nodes how can we get any overlaps=
?


--
This message was sent by Atlassian JIRA
(v6.2#6252)