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 4C49E3AC9 for ; Mon, 2 May 2011 16:52:38 +0000 (UTC) Received: (qmail 58906 invoked by uid 500); 2 May 2011 16:52:36 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 58880 invoked by uid 500); 2 May 2011 16:52:36 -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 58872 invoked by uid 99); 2 May 2011 16:52:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 May 2011 16:52:36 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of tyler@datastax.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-ww0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 May 2011 16:52:29 +0000 Received: by wwa36 with SMTP id 36so5563605wwa.25 for ; Mon, 02 May 2011 09:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.229.195 with SMTP id h45mr2771776weq.48.1304355127595; Mon, 02 May 2011 09:52:07 -0700 (PDT) Received: by 10.216.38.1 with HTTP; Mon, 2 May 2011 09:52:07 -0700 (PDT) X-Originating-IP: [64.132.24.248] In-Reply-To: References: Date: Mon, 2 May 2011 11:52:07 -0500 Message-ID: Subject: Re: Combining all CFs into one big one From: Tyler Hobbs To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=0016e644ccd40a916b04a24dd8ca --0016e644ccd40a916b04a24dd8ca Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 2, 2011 at 5:05 AM, David Boxenhorn wrote: > Wouldn't it be the case that the once-used rows in your batch process would > quickly be traded out of the cache, and replaced by frequently-used rows? > Yes, and you'll pay a cache miss penalty for each of the replacements. > This would be the case even if your batch process goes on for a long time, > since caching is done on a row-by-row basis. In effect, it would mean that > part of your cache is taken up by the batch process, much as if you > dedicated a permanent cache to the batch - except that it isn't permanent, > so it's better! > Right, but we didn't want to cache any of the batch CF in the first place, because caching that CF is worth very little. With separate CFs, we could explicitly give it no cache. Now we have no control over how much of the cache it evicts. --0016e644ccd40a916b04a24dd8ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 2, 2011 at 5:05 AM, David Boxenhorn = <david@taotown.co= m> wrote:
Wouldn't it be the case that the once-used rows in you= r batch process would quickly be traded out of the cache, and replaced by f= requently-used rows?

Yes, and you'll pay a c= ache miss penalty for each of the replacements.
=A0
This would be the case even if your batch process goes on for a l= ong time, since caching is done on a row-by-row basis. In effect, it would = mean that part of your cache is taken up by the batch process, much as if y= ou dedicated a permanent cache to the batch - except that it isn't perm= anent, so it's better!

Right, but we didn't want to cache any of t= he batch CF in the first place, because caching that CF is worth very littl= e.=A0 With separate CFs, we could explicitly give it no cache.=A0 Now we ha= ve no control over how much of the cache it evicts.

--0016e644ccd40a916b04a24dd8ca--