Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of rcoli@eventbrite.com designates
 209.85.215.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAZU44mN7j4xmbj5Yi_RAK=qAXEsuHddtfsO=hHomZoSUhmhAw@mail.gmail.com>
References: 
 <CAAZU44=aofn0wNey-yoXWAOu3OLoYaHgprWLZp=_EDxeDTJ1FQ@mail.gmail.com>
	<CAAZU44mN7j4xmbj5Yi_RAK=qAXEsuHddtfsO=hHomZoSUhmhAw@mail.gmail.com>
Date: Tue, 1 Jul 2014 18:40:12 -0700
Message-ID: 
 <CAEDUwd2XPsPbCovC=RyUcB_Nf=z+kW4i4S=NO2-OW8svZVsNyg@mail.gmail.com>
Subject: Re: Fetching ONE cell with a row cache hit takes 1 second on an idle
 box?
From: Robert Coli <rcoli@eventbrite.com>
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Content-Type: multipart/alternative; boundary=089e01493d582f74bd04fd2bf954

--089e01493d582f74bd04fd2bf954
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 1, 2014 at 6:06 PM, Kevin Burton <burton@spinn3r.com> wrote:

> you know.. one thing I failed to mention.. .is that this is going into a
> "bucket" and while it's a logical row, the physical row is like 500MB =E2=
=80=A6
> according to compaction logs.
>
> is the ENTIRE physical row going into the cache as one unit?  That's
> definitely going to be a problem in this model.  500MB is a big atomic un=
it.
>

Yes, the row cache is a row cache. It caches what the storage engine calls
rows, which CQL calls "partitions." [1] Rows have to be assembled from all
of their row fragments in Memtables/SSTables.

This is a big part of why the "off-heap" row cache's behavior of
invalidation on write is so bad for its overall performance. Updating a
single column in your 500MB row invalidates it and forces you to assemble
the entire 500MB row from disk.

The only valid use case for the current off-heap row cache seems to be :
very small, very uniform in size, very hot, and very rarely modified.

https://issues.apache.org/jira/browse/CASSANDRA-5357

Is the ticket for replacing the row cache and its unexpected
characteristics with something more like an actual query cache.

also.. I assume it's having to do a binary search within the physical row ?


Since the column level bloom filter's removal in 1.2, the only way it can
get to specific columns is via the index.

=3DRob
[1] https://issues.apache.org/jira/browse/CASSANDRA-6632

--089e01493d582f74bd04fd2bf954
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jul 1, 2014 at 6:06 PM, Kevin Burton <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:burton@spinn3r.com" target=3D"_blank">burton@spinn3r.com</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">you know.. one thing I failed to mention.=
. .is that this is going into a &quot;bucket&quot; and while it&#39;s a log=
ical row, the physical row is like 500MB =E2=80=A6 according to compaction =
logs.<div>
<br></div><div>

is the ENTIRE physical row going into the cache as one unit? =C2=A0That&#39=
;s definitely going to be a problem in this model. =C2=A0500MB is a big ato=
mic unit.</div></div></blockquote><div><br></div><div>Yes, the row cache is=
 a row cache. It caches what the storage engine calls rows, which CQL calls=
 &quot;partitions.&quot; [1] Rows have to be assembled from all of their ro=
w fragments in Memtables/SSTables.</div>
<div><br></div><div>This is a big part of why the &quot;off-heap&quot; row =
cache&#39;s behavior of invalidation on write is so bad for its overall per=
formance. Updating a single column in your 500MB row invalidates it and for=
ces you to assemble the entire 500MB row from disk.=C2=A0</div>
<div><br></div><div>The only valid use case for the current off-heap row ca=
che seems to be : very small, very uniform in size, very hot, and very rare=
ly modified.</div><div><br></div><div><a href=3D"https://issues.apache.org/=
jira/browse/CASSANDRA-5357">https://issues.apache.org/jira/browse/CASSANDRA=
-5357</a></div>
<div><br></div><div>Is the ticket for replacing the row cache and its unexp=
ected characteristics with something more like an actual query cache.</div>=
<div><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex">
also.. I assume it&#39;s having to do a binary search within the physical r=
ow ?=C2=A0</blockquote><div><br></div><div>Since the column level bloom fil=
ter&#39;s removal in 1.2, the only way it can get to specific columns is vi=
a the index.</div>
</div><div><br></div><div>=3DRob</div><div>[1]=C2=A0<a href=3D"https://issu=
es.apache.org/jira/browse/CASSANDRA-6632">https://issues.apache.org/jira/br=
owse/CASSANDRA-6632</a></div></div></div></div>

--089e01493d582f74bd04fd2bf954--