Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 22595 invoked from network); 5 Nov 2010 18:50:08 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 5 Nov 2010 18:50:08 -0000 Received: (qmail 64678 invoked by uid 500); 5 Nov 2010 18:50:37 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 64660 invoked by uid 500); 5 Nov 2010 18:50:37 -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 64652 invoked by uid 99); 5 Nov 2010 18:50:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Nov 2010 18:50:37 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of driftx@gmail.com designates 209.85.214.44 as permitted sender) Received: from [209.85.214.44] (HELO mail-bw0-f44.google.com) (209.85.214.44) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Nov 2010 18:50:29 +0000 Received: by bwz12 with SMTP id 12so3203468bwz.31 for ; Fri, 05 Nov 2010 11:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=UYbsE32hv0CBfdXRulvN7OGKeRaNB52lBPUQZP60LlE=; b=bONHYWRvQbvhJf0r8IDX8D3sPvhRRkTWPqzhq/n8z7m0Ob5r5s+yNb/PnklPfmMP6Q mTvazDMAbfqkOTBHKQoO9uO7iWpjJ8TM/1SObt7+6QyNhQxeHlkZ/reVDAJ4xrwnmDq4 hlMNsA1dFEftvH5AhogjKQJ6+Lmf0rHhRGFlM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=sx78QK7XQNiaBB4rTHo95OX9zl+ffimo4FnK/67JQWInDXVIqfKtK10bYZRt2JvsxG J8Ke48fs0HW5d5LfSqgCWggXW8E7PRNGHaXxj5WEr56mCTVy72mWxSmPm0y/pRKQP2e8 ILWdq4gEgXtexl5yTpPdQCGZ7FsHa/WfQFNf0= Received: by 10.204.16.209 with SMTP id p17mr2113934bka.157.1288983009396; Fri, 05 Nov 2010 11:50:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.163.142 with HTTP; Fri, 5 Nov 2010 11:49:38 -0700 (PDT) In-Reply-To: References: From: Brandon Williams Date: Fri, 5 Nov 2010 13:49:38 -0500 Message-ID: Subject: Re: row cache vs frequent row updates vs write through row cache To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=0003255542a66587dd049452be3a X-Virus-Checked: Checked by ClamAV on apache.org --0003255542a66587dd049452be3a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 5, 2010 at 1:41 PM, Jeremy Davis wrote: > I saw in the Riptano "Tuning Cassandra" slide deck that the row cache can > be detrimental if there are a lot of updates to the cached row. Is this > because the cache is not write through, and every update necessitates > creation of a new row? > I see there is an open issue: > https://issues.apache.org/jira/browse/CASSANDRA-860 for implementing > write through in 0.8. The problem is that if the row is being updated a lot, the cache is turning over quickly, and this exerts GC pressure on the JVM. Even if it were write-through, row cache is probably a bad match for this kind of row, it's much better at mostly static rows. Rely on keycache and OS file cache for these instead. -Brandon --0003255542a66587dd049452be3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 5, 2010 at 1:41 PM, Jeremy Davis <jerdavis= .cassandra@gmail.com> wrote:
I saw in the Riptano "Tuning Cassandra" slide deck that the row c= ache can be detrimental if there are a lot of updates to the cached row. Is= this because the cache is not write through, and every update necessitates= creation of a new row?
I see there is an open issue: https://issues.apache.org/jira/browse/= CASSANDRA-860=A0 for implementing write through in 0.8.

The problem is that if the row is being updated a lot, the c= ache is turning over quickly, and this exerts GC pressure on the JVM. =A0Ev= en if it were write-through, row cache is probably a bad match for this kin= d of row, it's much better at mostly static rows. =A0Rely on keycache a= nd OS file cache for these instead.

-Brandon=A0
--0003255542a66587dd049452be3a--