Return-Path: Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org Received: (qmail 81408 invoked from network); 17 Feb 2010 01:36:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 17 Feb 2010 01:36:29 -0000 Received: (qmail 16124 invoked by uid 500); 17 Feb 2010 01:36:29 -0000 Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org Received: (qmail 16104 invoked by uid 500); 17 Feb 2010 01:36:29 -0000 Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-user@incubator.apache.org Delivered-To: mailing list cassandra-user@incubator.apache.org Received: (qmail 16095 invoked by uid 99); 17 Feb 2010 01:36:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Feb 2010 01:36:29 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of weijunli@gmail.com designates 209.85.222.172 as permitted sender) Received: from [209.85.222.172] (HELO mail-pz0-f172.google.com) (209.85.222.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Feb 2010 01:36:20 +0000 Received: by pzk2 with SMTP id 2so556363pzk.21 for ; Tue, 16 Feb 2010 17:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=mPYD3osvdmcK+14vWIzIavWmn4fKatliW3Ds5CoivNA=; b=gvjVEQlMQHOvEm1Z+O/An24D7xsGqIg5PH4tL2p4BnP+NcGZesgBPJdklnRcmnWjhv 3mTKq4brQyKAwYU5Cq2/gDnu8aLi9UTJpdk90P48p4iJuUCt650E9aaWk6BuzYsbvMT5 iMSs+MjEXp9BvkST01jcKERTJ9YPomXlQbXos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=f4FzA/jW5tKPfYLGxUdvbnu9Vg63qX1mDwh0pgodspXZcqWJPgTYA1P1UP4K98QKcW XN8c1dwStc9Wdy9RgUjY3VePXpqI0YaI3oJBsTqeleDTh2OdCwILhsug8SPnFWXC8Sdm ILnZb+Ep1JOw6CV5jMrFD0UPxAu0LtHPtCJ1w= MIME-Version: 1.0 Received: by 10.114.5.13 with SMTP id 13mr4887969wae.222.1266370559417; Tue, 16 Feb 2010 17:35:59 -0800 (PST) In-Reply-To: References: Date: Tue, 16 Feb 2010 17:35:59 -0800 Message-ID: Subject: Re: Testing row cache feature in trunk: write should put record in cache From: Weijun Li To: cassandra-user@incubator.apache.org Content-Type: multipart/alternative; boundary=0016e649ce2259264d047fc1df61 X-Virus-Checked: Checked by ClamAV on apache.org --0016e649ce2259264d047fc1df61 Content-Type: text/plain; charset=ISO-8859-1 Yes it will be nice if you can add a parameter in storage-conf.xml to enable write-through to row cache. There are many cases that require the new keys to be immediately available for read. In my case I'm thinking of caching 30-50% of all records in memory to reduce read latency. Thanks, -Weijun On Tue, Feb 16, 2010 at 5:17 PM, Jonathan Ellis wrote: > On Tue, Feb 16, 2010 at 7:11 PM, Weijun Li wrote: > > Just started to play with the row cache feature in trunk: it seems to be > > working fine so far except that for RowsCached parameter you need to > specify > > number of rows rather than a percentage (e.g., "20%" doesn't work). > > 20% works, but it's 20% of the rows at server startup. So on a fresh > start that is zero. > > Maybe we should just get rid of the % feature... > > > The problem is: when you write to Cassandra it doesn't seem to put the > new > > keys in row cache (it is said to update instead invalidate if the entry > is > > already in cache). Is it easy to implement this feature? > > It's deliberately not done. For many (most?) workloads you don't want > fresh writes blowing away your read cache. The code is in > Table.apply: > > ColumnFamily cachedRow = > cfs.getRawCachedRow(mutation.key()); > if (cachedRow != null) > cachedRow.addAll(columnFamily); > > I think it would be okay to have a WriteThrough option for what you're > asking, though. > > -Jonathan > --0016e649ce2259264d047fc1df61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes it will be nice if you can add a parameter in storage-conf.xml to enabl= e write-through to row cache. There are many cases that require the new key= s to be immediately available for read. In my case I'm thinking of cach= ing 30-50% of all records in memory to reduce read latency.

Thanks,

-Weijun

On Tue, Feb 16= , 2010 at 5:17 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
On Tue, Feb 16, 2010 at 7:11 PM, Weijun Li <weijunli@gmail.com> wrote:
> Just started to play with the row cache feature in trunk: it seems to = be
> working fine so far except that for RowsCached parameter you need to s= pecify
> number of rows rather than a percentage (e.g., "20%" doesn&#= 39;t work).

20% works, but it's 20% of the rows at server startup. =A0So on a= fresh
start that is zero.

Maybe we should just get rid of the % feature...

> The problem is: when you write to Cassandra it doesn't seem to put= the new
> keys in row cache (it is said to update instead invalidate if the entr= y is
> already in cache). Is it easy to implement this feature?

It's deliberately not done. =A0For many (most?) workloads you don= 't want
fresh writes blowing away your read cache. =A0The code is in
Table.apply:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ColumnFamily cachedRow =3D cfs.getRawCached= Row(mutation.key());
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (cachedRow !=3D null)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cachedRow.addAll(columnFamily);

I think it would be okay to have a WriteThrough option for what you're<= br> asking, though.

-Jonathan

--0016e649ce2259264d047fc1df61--