From user-return-36278-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Sun Sep 1 07:06:52 2013 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 60DF010EC2 for ; Sun, 1 Sep 2013 07:06:52 +0000 (UTC) Received: (qmail 20503 invoked by uid 500); 1 Sep 2013 07:06:49 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 20482 invoked by uid 500); 1 Sep 2013 07:06:48 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 20472 invoked by uid 99); 1 Sep 2013 07:06:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Sep 2013 07:06:46 +0000 X-ASF-Spam-Status: No, hits=2.4 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of asf11@outlook.com designates 65.54.190.142 as permitted sender) Received: from [65.54.190.142] (HELO bay0-omc3-s4.bay0.hotmail.com) (65.54.190.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Sep 2013 07:06:41 +0000 Received: from BAY169-W44 ([65.54.190.187]) by bay0-omc3-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Sep 2013 00:06:20 -0700 X-TMN: [SkRXG0Bx3FptAxayfkJ5HqVS5fayjv7n] X-Originating-Email: [asf11@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_4303e55e-d9d0-4bba-811b-6e3885ac162f_" From: S C To: "user@cassandra.apache.org" Subject: RE: row cache Date: Sun, 1 Sep 2013 02:06:20 -0500 Importance: Normal In-Reply-To: <5217A2AF.3000803@dehora.net> References: <732CBD5A9F0448358ABDCD02AFA30693@quantcast.com> ,<5217A2AF.3000803@dehora.net> MIME-Version: 1.0 X-OriginalArrivalTime: 01 Sep 2013 07:06:20.0453 (UTC) FILETIME=[C2B09D50:01CEA6E1] X-Virus-Checked: Checked by ClamAV on apache.org --_4303e55e-d9d0-4bba-811b-6e3885ac162f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is my understanding that row cache is on the memory (Not on disk). It co= uld live on heap or native memory depending on the cache provider? Is that = right?=20 -SC > Date: Fri=2C 23 Aug 2013 18:58:07 +0100 > From: bill@dehora.net > To: user@cassandra.apache.org > Subject: Re: row cache >=20 > I can't emphasise enough testing row caching against your workload for=20 > sustained periods and comparing results to just leveraging the=20 > filesystem cache and/or ssds. That said. The default off-heap cache can=20 > work for structures that don't mutate frequently=2C and whose rows are no= t=20 > very wide such that the in-and-out-of heap serialization overhead is=20 > minimised (I've seen the off-heap cache slow a system down because of=20 > serialization costs). The on-heap can do update in place=2C which is nice= =20 > for more frequently changing structures=2C and for larger structures=20 > because it dodges the off-heap's serialization overhead. One problem=20 > I've experienced with the on-heap cache is the cache working set=20 > exceeding allocated space=2C resulting in GC pressure from sustained=20 > thrash/evictions. >=20 > Neither cache seems suitable for wide row + slicing usecases=2C eg time=20 > series data or CQL tables whose compound keys create wide rows under the= =20 > hood. >=20 > Bill >=20 >=20 > On 2013/08/23 17:30=2C Robert Coli wrote: > > On Thu=2C Aug 22=2C 2013 at 7:53 PM=2C Faraaz Sareshwala > > > wrote: > > > > According to the datastax documentation [1]=2C there are two types = of > > row cache providers: > > > > ... > > > > The off-heap row cache provider does indeed invalidate rows. We're > > going to look into using the ConcurrentLinkedHashCacheProvider. Tim= e > > to read some source code! :) > > > > > > Thanks for the follow up... I'm used to thinking of the > > ConcurrentLinkedHashCacheProvider as "the row cache" and forgot that > > SerializingCacheProvider might have different invalidation behavior. > > Invalidating the whole row on write seems highly likely to reduce the > > overall performance of such a row cache. :) > > > > The criteria for use of row cache mentioned up-thread remain relevant. > > In most cases=2C you probably don't actually want to use the row cache. > > Especially if you're using ConcurrentLinkedHashCacheProvider and > > creating long lived=2C on heap objects. > > > > =3DRob >=20 = --_4303e55e-d9d0-4bba-811b-6e3885ac162f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It is my understanding that row = cache is on the memory (Not on disk). It could live on heap or native memor= y depending on the cache provider? Is that right? =3B

-SC


>=3B Date: Fri=2C 23 = Aug 2013 18:58:07 +0100
>=3B From: bill@dehora.net
>=3B To: user@= cassandra.apache.org
>=3B Subject: Re: row cache
>=3B
>=3B = I can't emphasise enough testing row caching against your workload for
= >=3B sustained periods and comparing results to just leveraging the
&= gt=3B filesystem cache and/or ssds. That said. The default off-heap cache c= an
>=3B work for structures that don't mutate frequently=2C and whose= rows are not
>=3B very wide such that the in-and-out-of heap seriali= zation overhead is
>=3B minimised (I've seen the off-heap cache slow = a system down because of
>=3B serialization costs). The on-heap can d= o update in place=2C which is nice
>=3B for more frequently changing = structures=2C and for larger structures
>=3B because it dodges the of= f-heap's serialization overhead. One problem
>=3B I've experienced wi= th the on-heap cache is the cache working set
>=3B exceeding allocate= d space=2C resulting in GC pressure from sustained
>=3B thrash/evicti= ons.
>=3B
>=3B Neither cache seems suitable for wide row + slici= ng usecases=2C eg time
>=3B series data or CQL tables whose compound = keys create wide rows under the
>=3B hood.
>=3B
>=3B Bill<= br>>=3B
>=3B
>=3B On 2013/08/23 17:30=2C Robert Coli wrote:>=3B >=3B On Thu=2C Aug 22=2C 2013 at 7:53 PM=2C Faraaz Sareshwala>=3B >=3B <=3Bfsareshwala@quantcast.com <=3Bmailto:fsareshwala@qua= ntcast.com>=3B>=3B wrote:
>=3B >=3B
>=3B >=3B Accordi= ng to the datastax documentation [1]=2C there are two types of
>=3B &g= t=3B row cache providers:
>=3B >=3B
>=3B >=3B ...
>= =3B >=3B
>=3B >=3B The off-heap row cache provider does indeed= invalidate rows. We're
>=3B >=3B going to look into using the C= oncurrentLinkedHashCacheProvider. Time
>=3B >=3B to read some so= urce code! :)
>=3B >=3B
>=3B >=3B
>=3B >=3B Thanks for= the follow up... I'm used to thinking of the
>=3B >=3B ConcurrentLi= nkedHashCacheProvider as "the row cache" and forgot that
>=3B >=3B S= erializingCacheProvider might have different invalidation behavior.
>= =3B >=3B Invalidating the whole row on write seems highly likely to reduc= e the
>=3B >=3B overall performance of such a row cache. :)
>= =3B >=3B
>=3B >=3B The criteria for use of row cache mentioned up-= thread remain relevant.
>=3B >=3B In most cases=2C you probably don'= t actually want to use the row cache.
>=3B >=3B Especially if you're= using ConcurrentLinkedHashCacheProvider and
>=3B >=3B creating long= lived=2C on heap objects.
>=3B >=3B
>=3B >=3B =3DRob
>= =3B
= --_4303e55e-d9d0-4bba-811b-6e3885ac162f_--