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 660709286 for ; Wed, 16 May 2012 09:24:13 +0000 (UTC) Received: (qmail 15532 invoked by uid 500); 16 May 2012 09:24:11 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 14783 invoked by uid 500); 16 May 2012 09:24:05 -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 14754 invoked by uid 99); 16 May 2012 09:24:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 May 2012 09:24:04 +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-a44.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 May 2012 09:23:56 +0000 Received: from homiemail-a44.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a44.g.dreamhost.com (Postfix) with ESMTP id 65B9611805C for ; Wed, 16 May 2012 02:23:34 -0700 (PDT) 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=NbFOMw+Mn2 HKS7/qQlSSiH5MTbj+qBbVuGyV/9y7HotiHIygSuQ+vRss4sNR5RTDBASmp4/pGE nFa4bh2Hv+1AgiYFxZ0hG+OJv8HA8Y1H8mG0pJTs1MMdKZBVrngo0XhCrTpNtcFJ 7lts3VCUVUnydiiLtb6xSwk/4rlzc9x60= 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=uVSOy3iIHMAZVTLq +wYf3qGmMsE=; b=cGoNtHSWOHBkcrVRcwVTghFmA3OJ4jIzeBjZ0hRycfMgV9gZ AJwLav6Mum1rV/GKuSBWZmLtGCpEuUxfVCdLADy2N+zTd/9XhbbEXEpthHga4Hc2 V7TSZxbiZFtQtExGLwil3DQyBXGL5C31hx9oDdNDth476/RBBF/7a7aLtq0= Received: from [172.16.1.4] (unknown [203.86.207.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a44.g.dreamhost.com (Postfix) with ESMTPSA id D25D6118058 for ; Wed, 16 May 2012 02:23:33 -0700 (PDT) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_6CDE57F6-9C3C-4E06-ADB4-E2B47B292FD9" Subject: Re: Frequently Updated Wide Rows - Suggestions Date: Wed, 16 May 2012 21:23:31 +1200 In-Reply-To: To: user@cassandra.apache.org References: Message-Id: X-Mailer: Apple Mail (2.1257) --Apple-Mail=_6CDE57F6-9C3C-4E06-ADB4-E2B47B292FD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 That scenario can result in slower reads than narrow rows that are = updated less frequently.=20 Like most things it depends. Do you have a feel for how wide and what = the update pattern is like ?=20 Things like levelled compaction = (http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra) = can help. It's also pretty easy to run up a proof of concept to see what = the read performance is like.=20 Hope that helps.=20 ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 15/05/2012, at 9:32 PM, Praveen Baratam wrote: > Hello Everybody, >=20 > In my use case we use Wide Rows whose columns are frequently updated, = deleted and created. >=20 > I was wondering if this case fits the Cassandra pattern and if there = are any precautions to be taken. >=20 > Kindly advice! >=20 > Praveen=20 --Apple-Mail=_6CDE57F6-9C3C-4E06-ADB4-E2B47B292FD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 That = scenario can result in slower reads than narrow rows that are updated = less frequently. 

Like most things it = depends. Do you have a feel for how wide and what the update = pattern is like ? 

Things like = levelled compaction (http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassa= ndra) can help. It's also pretty easy to run up a proof of concept = to see what the read performance is = like. 

Hope that = helps. 

http://www.thelastpickle.com

On 15/05/2012, at 9:32 PM, Praveen Baratam wrote:

Hello = Everybody,

In my use case we use Wide Rows whose = columns are frequently updated, deleted and = created.

I was wondering if this case fits the = Cassandra pattern and if there are any precautions to be taken.

Kindly = advice!

Praveen 

= --Apple-Mail=_6CDE57F6-9C3C-4E06-ADB4-E2B47B292FD9--