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 224C910225 for ; Thu, 15 Aug 2013 05:57:29 +0000 (UTC) Received: (qmail 80844 invoked by uid 500); 15 Aug 2013 05:57:26 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 80548 invoked by uid 500); 15 Aug 2013 05:57:18 -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 80536 invoked by uid 99); 15 Aug 2013 05:57:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 05:57:16 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of fsareshwala@quantcast.com designates 64.78.22.18 as permitted sender) Received: from [64.78.22.18] (HELO EXHUB017-3.exch017.msoutlookonline.net) (64.78.22.18) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 05:57:08 +0000 Received: from [10.0.0.10] (24.4.9.212) by smtpx17.msoutlookonline.net (64.78.22.38) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 14 Aug 2013 22:56:46 -0700 Date: Wed, 14 Aug 2013 22:56:45 -0700 From: Faraaz Sareshwala To: user@cassandra.apache.org Message-ID: Subject: row cache X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="520c6d9d_8edbdab_5bfe" X-Virus-Checked: Checked by ClamAV on apache.org --520c6d9d_8edbdab_5bfe Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline At the Cassandra 2013 conference, Axel Liljencrantz from Spotify discussed various cassandra gotchas in his talk on "How Not to Use Cassandra." One of the sections of his talk was on the row cache. If you weren't at the talk, or don't remember it, the video is up on youtube [1]. The discussion on the row cache starts at about 5:35. The takeaway from his row cache bit is that the row cache stores the full row: Cache misses on a single column get silently turn into a full row read in order to cache the full row All writes invalidate the entire row (updates thrown out the cached row) I'm mostly interested in his second point. Is he saying that a single column mutation on a row which happens to be in the row cache results in the row cache completely discarding the row and waiting for another read of the row in order to bring it back in? I must have misunderstood what he said because there is no way the row cache would be effective at all if that is how it worked. Most likely, it is smart and updates both the cache and real storage, or sets a dirty bit and writes through on eviction or some other sane eviction policy. I have yet to go through the source code for the row cache. I do plan to do that. Can someone point me to documentation on the row cache internals? All I've found online so far is small discussion about it and how to enable it. Thank you, Faraaz [1] http://www.youtube.com/watch?v=0u-EKJBPrj8 --520c6d9d_8edbdab_5bfe Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
At the Cassandra 2013 conference, Axel Liljencr= antz from Spotify discussed various cassandra gotchas in his talk on= =22How Not to Use Cassandra.=22 One of the sections of his talk was= on the row cache. If you weren't at the talk, or don't remember it, the = video is up on youtube =5B1=5D. The discussion on the row cache= starts at about 5:35.

The takeaway from his row= cache bit is that the row cache stores the full row:
  • C= ache misses on a single column get silently turn into a full row read in = order to cache the full row
  • All writes invalidate the entire row = (updates thrown out the cached row)
I'm mostly intere= sted in his second point. Is he saying that a single column mutation on a= row which happens to be in the row cache results in the row cache comple= tely discarding the row and waiting for another read of the row in order = to bring it back in=3F

I must have misunderstood= what he said because there is no way the row cache would be effective at= all if that is how it worked. Most likely, it is smart and updates = both the cache and real storage, or sets a dirty bit and writes thro= ugh on eviction or some other sane eviction policy.

I have yet to go through the source code for the row cache. I do= plan to do that. Can someone point me to documentation on the row cache = internals=3F All I've found online so far is small discussion about it an= d how to enable it.

Thank you,
<= div>=46araaz

<= /div> --520c6d9d_8edbdab_5bfe--