From user-return-31808-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Tue Feb 12 04:23:14 2013 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 09738ED6C for ; Tue, 12 Feb 2013 04:23:13 +0000 (UTC) Received: (qmail 57775 invoked by uid 500); 12 Feb 2013 04:23:11 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 57472 invoked by uid 500); 12 Feb 2013 04:23:10 -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 57429 invoked by uid 99); 12 Feb 2013 04:23:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Feb 2013 04:23:09 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [63.146.121.108] (HELO mail.venarc.com) (63.146.121.108) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Feb 2013 04:23:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.venarc.com (Postfix) with ESMTP id 825D46F00002 for ; Mon, 11 Feb 2013 20:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at venarc.com Received: from mail.venarc.com ([127.0.0.1]) by localhost (mail.venarc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO+YXnCZsr9X for ; Mon, 11 Feb 2013 20:22:39 -0800 (PST) Received: from [192.168.1.2] (drew-home [108.60.62.58]) by mail.venarc.com (Postfix) with ESMTPSA id AAC1B6F00001 for ; Mon, 11 Feb 2013 20:22:39 -0800 (PST) From: Drew Kutcharian Content-Type: multipart/alternative; boundary="Apple-Mail=_F633F7B5-69C3-444C-83EE-99A37CB6C60F" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Operation Consideration with Counter Column Families Date: Mon, 11 Feb 2013 20:22:39 -0800 References: <2608F151-F38D-4010-991F-478A5D172A9C@venarc.com> <126B9DC3-37B3-4DB1-8061-5ECB8A250201@venarc.com> <912E6E30-F356-4656-B3AB-998C7E05618F@thelastpickle.com> To: user@cassandra.apache.org In-Reply-To: <912E6E30-F356-4656-B3AB-998C7E05618F@thelastpickle.com> X-Mailer: Apple Mail (2.1499) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_F633F7B5-69C3-444C-83EE-99A37CB6C60F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For anyone interested, I came across this video where Sylvain explains = how counters are actually implemented in Cassandra. http://vimeo.com/26011102 On Feb 6, 2013, at 8:08 PM, aaron morton = wrote: >> Thanks Aaron, so will there only be one "value" for each counter = column per sstable just like regular columns? > Yes.=20 >=20 >> For some reason I was under the impression that Cassandra keeps a = log of all the increments not the actual value. > Not as far as I understand.=20 >=20 > Cheers > =20 > ----------------- > Aaron Morton > Freelance Cassandra Developer > New Zealand >=20 > @aaronmorton > http://www.thelastpickle.com >=20 > On 6/02/2013, at 11:15 AM, Drew Kutcharian wrote: >=20 >> Thanks Aaron, so will there only be one "value" for each counter = column per sstable just like regular columns? For some reason I was = under the impression that Cassandra keeps a log of all the increments = not the actual value. >>=20 >>=20 >> On Feb 5, 2013, at 12:36 PM, aaron morton = wrote: >>=20 >>>> Are there any specific operational considerations one should make = when using counter columns families? >>> Performance, as they incur a read and a write.=20 >>> There were some issues with overcounts in log replay (see the = changes.txt).=20 >>> =20 >>>> How are counter column families stored on disk?=20 >>> Same as regular CF's.=20 >>>=20 >>>> How do they effect compaction? >>> None. >>>=20 >>> Cheers >>>=20 >>> ----------------- >>> Aaron Morton >>> Freelance Cassandra Developer >>> New Zealand >>>=20 >>> @aaronmorton >>> http://www.thelastpickle.com >>>=20 >>> On 6/02/2013, at 7:47 AM, Drew Kutcharian wrote: >>>=20 >>>> Hey Guys, >>>>=20 >>>> Are there any specific operational considerations one should make = when using counter columns families? How are counter column families = stored on disk? How do they effect compaction? >>>>=20 >>>> -- Drew >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_F633F7B5-69C3-444C-83EE-99A37CB6C60F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii For = anyone interested, I came across this video where Sylvain explains how = counters are actually implemented in Cassandra.



On Feb 6, 2013, at 8:08 PM, aaron morton = <aaron@thelastpickle.com> = wrote:

Yes. 

 For some reason I = was under the impression that Cassandra keeps a log of all the = increments not the actual value.
Not as far as I = understand. 

Cheers
 
http://www.thelastpickle.com

On 6/02/2013, at 11:15 AM, Drew Kutcharian <drew@venarc.com> wrote:

Thanks Aaron, so = will there only be one "value" for each counter column per = sstable just like regular columns? For some reason I was under the = impression that Cassandra keeps a log of all the increments not the = actual value.


On Feb 5, 2013, at 12:36 = PM, aaron morton <aaron@thelastpickle.com> = wrote:

Are there any specific operational = considerations one should make when using counter columns = families?
Performance, as they incur a read and a = write. 
There were some issues with overcounts in log replay = (see the changes.txt). 
 
 How are counter column families stored on = disk? 
Same as regular = CF's. 

How do = they effect = compaction?
None.

Cheers
http://www.thelastpickle.com

On 6/02/2013, at 7:47 AM, Drew Kutcharian <drew@venarc.com> wrote:

Hey = Guys,

Are there any specific operational considerations one = should make when using counter columns families? How are counter column = families stored on disk? How do they effect compaction?

-- = Drew





= --Apple-Mail=_F633F7B5-69C3-444C-83EE-99A37CB6C60F--