From user-return-6383-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Thu Jun 03 17:18:59 2010 Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 32636 invoked from network); 3 Jun 2010 17:18:59 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 3 Jun 2010 17:18:59 -0000 Received: (qmail 18309 invoked by uid 500); 3 Jun 2010 17:18:58 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 18274 invoked by uid 500); 3 Jun 2010 17:18:58 -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 18253 invoked by uid 99); 3 Jun 2010 17:18:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Jun 2010 17:18:58 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=AWL,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dking@ketralnis.com designates 68.183.67.83 as permitted sender) Received: from [68.183.67.83] (HELO ketralnis.com) (68.183.67.83) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Jun 2010 17:18:50 +0000 Received: from [192.168.1.6] (adsl-99-191-194-126.dsl.pltn13.sbcglobal.net [99.191.194.126]) (authenticated bits=0) by ketralnis.com (8.14.3/8.14.3) with ESMTP id o53HHo4g015166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 3 Jun 2010 10:18:23 -0700 (PDT) (envelope-from dking@ketralnis.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: Effective cache size From: David King In-Reply-To: Date: Thu, 3 Jun 2010 10:17:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6A9F8ED2-933E-491D-BEC0-A0F8D7210594@ketralnis.com> To: user@cassandra.apache.org X-Mailer: Apple Mail (2.1078) X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on melchoir.ketralnis.com X-Old-Spam-Status: No, score=0.4 required=5.0 tests=RDNS_DYNAMIC autolearn=disabled version=3.3.0 >> So with the row cache, that first node (the primary replica) is the = one that has that row cached, yes? > No, it's the closest node as determined by snitch.sortByProximity. And with the default snitch, rack-unaware placement, random partitioner, = and all nodes up, that's the primary replica, right? > any given node X will never know whether another node Y has a row = cached or not. the overhead for communicating that level of detail = would be totally prohibitive. all caching does is speed the read, once a = request is received for data local to a given node. no more, no less. Yes, that's my concern, but the details significantly affect the = effective size of the cache (in the afoorementioned case, the details = place the effective size at either 6 million or 18 million, a 3x = difference). So given CL=3D=3DONE reads, only the actually read node (which will be = the primary replica given the default placement strategy and snitch) = will cache the item, right? The checksum-checking doesn't cause the row = to be cached on the non-read nodes? If I read with CL=3D=3DQUORUM in an RF=3D=3D3 environment, do both read = nodes them cache the item, or only the primary replica?=