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 963A59017 for ; Sun, 5 Feb 2012 20:57:24 +0000 (UTC) Received: (qmail 21357 invoked by uid 500); 5 Feb 2012 20:57:22 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 21295 invoked by uid 500); 5 Feb 2012 20:57:21 -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 21287 invoked by uid 99); 5 Feb 2012 20:57:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Feb 2012 20:57:21 +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: local policy) Received: from [208.113.200.5] (HELO homiemail-a54.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Feb 2012 20:57:13 +0000 Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 869643A4065 for ; Sun, 5 Feb 2012 12:56:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; q=dns; s=thelastpickle.com; b=EuarCYPF5o IMaF2MFc0xQGfCivESSBtdyqc7zjjof2GlkKPYfzCr5IsTXLUehQjyS2yNzr6AGy a3A/a5zOoYCvjkoyxAyL32mH4lA4NEOAxRIi17GnWk3DvABQ5WxDc1J6LXWSfmmx AnPJtk6SX9LySEfhCISmD4DY+/dyrfiJo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; s=thelastpickle.com; bh=eL91xAlitn7V32XH ef418TMj7QQ=; b=bzeKN8MYwySXZy3t+5ityp2pr//obtGE5oh6ba0aSgSgdkSf ycajCjHPYkLY7v+BTrlbyz7Y3yxLnRYObDrNqSMXJArwXPk7a5ZlAVh4BVzbsffd OgvEq550Ug/ZYNATXiF8s4FMyx4foNqf6AWXPQE5HwB9vTF3sW+1XaJnRiY= Received: from [172.16.1.3] (125-236-193-159.adsl.xtra.co.nz [125.236.193.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id D0F9D3A4057 for ; Sun, 5 Feb 2012 12:56:50 -0800 (PST) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_18F8099C-1AF3-46B7-9473-5C1817B2A961" Subject: Re: Write latency of counter updates across multiple rows Date: Mon, 6 Feb 2012 09:56:47 +1300 In-Reply-To: To: user@cassandra.apache.org References: Message-Id: X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_18F8099C-1AF3-46B7-9473-5C1817B2A961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I'm not thinking about counters specifically here, and assuming you are = sending batch mutations of the same size=85=20 The mutations (inserts, counter increments) for a row are turned into a = single task server side, and are then processed in a serial fashion. If = you send a mutation for 2 rows it will be turned into two tasks, which = can then be processed in parallel.=20 There is an point of dimensioning returns here. Each row you write to or = read from will become a task, if you write to 1,000 rows at once you = will put 1,000 tasks in the thread pool which typically has 32 = concurrent threads. This may block / add latency to other requests. It's = more of an issue with reads than writes.=20 Does that apply to your situation ?=20 ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 4/02/2012, at 1:19 AM, Amit Chavan wrote: >=20 > Hi, >=20 > In our use case, we maintain minute-wise roll ups for different = metrics. These are stored in a counter column family where the row key = is a composite containing the timestamp rounded to the last minute and = an integer between 0-9 (This integer is calculated as the MD5 hash of = the metric mod 10). The column names are the metrics we wish to track. = Typically, each row has about 100,000 counters. >=20 > We tested two scenarios. The first one is as mentioned above. In this = case we got a per write latency of about 80 micro-seconds to 100 = micro-seconds. >=20 > In the other scenario, we calculated the integer in the row key as mod = 100. In this case we observed a per write latency of 50 micro-seconds to = 70 micro-seconds. >=20 > I wish to understand why updates to counters were faster as they got = spread across multiple rows? >=20 > Cluster summary : 4 nodes running Cassandra 1.0.5. Each with 8 cores, = 32G RAM, 10G Cassandra heap. We are using replication factor of 2. >=20 >=20 > --=20 > Thanks! > Amit Chavan >=20 --Apple-Mail=_18F8099C-1AF3-46B7-9473-5C1817B2A961 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I'm = not thinking about counters specifically here, and assuming you are = sending batch mutations of the same size=85 

The = mutations (inserts, counter increments) for a row are turned into a = single task server side, and are then processed in a serial fashion. If = you send a mutation for 2 rows it will be turned into two tasks, which = can then be processed in parallel. 

There is an = point of dimensioning returns here. Each row you write to or read from = will become a task, if you write to 1,000 rows at once you will put = 1,000 tasks in the thread pool which typically has 32 concurrent = threads. This may block / add latency to other requests. It's more of an = issue with reads than writes. 

Does that = apply to your situation ? 

http://www.thelastpickle.com

On 4/02/2012, at 1:19 AM, Amit Chavan wrote:


Hi,

In our use case, we = maintain minute-wise roll ups for different metrics. These are stored in = a counter column family where the row key is a composite containing the = timestamp rounded to the last minute and an integer between 0-9 (This = integer is calculated as the MD5 hash of the metric mod 10). The column = names are the metrics we wish to track. Typically, each row has about = 100,000 counters.

We tested two scenarios. The first one is as = mentioned above. In this case we got a per write latency of about 80 = micro-seconds to 100 micro-seconds.

In the = other scenario, we calculated the integer in the row key as mod 100. In = this case we observed a per write latency of 50 micro-seconds to 70 = micro-seconds.

I wish to understand why updates to counters were = faster as they got spread across multiple = rows?

Cluster summary : 4 nodes running = Cassandra 1.0.5. Each with 8 cores, 32G RAM, 10G Cassandra heap. We are = using replication factor of 2.


--
Thanks!
Amit Chavan


= --Apple-Mail=_18F8099C-1AF3-46B7-9473-5C1817B2A961--