From user-return-18410-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Mon Jul 4 14:08:47 2011 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 B953F6E20 for ; Mon, 4 Jul 2011 14:08:47 +0000 (UTC) Received: (qmail 51813 invoked by uid 500); 4 Jul 2011 14:08:45 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 51755 invoked by uid 500); 4 Jul 2011 14:08:44 -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 51747 invoked by uid 99); 4 Jul 2011 14:08:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jul 2011 14:08:44 +0000 X-ASF-Spam-Status: No, hits=4.0 required=5.0 tests=FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dan.hendry.junk@gmail.com designates 209.85.214.172 as permitted sender) Received: from [209.85.214.172] (HELO mail-iw0-f172.google.com) (209.85.214.172) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jul 2011 14:08:40 +0000 Received: by iwn39 with SMTP id 39so5558967iwn.31 for ; Mon, 04 Jul 2011 07:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=XNxyh/9LfHCLWYKIKjAYuDn8kLHvjKAqm4uFgpKLUAo=; b=FBS4ADDQnl9N/0/NocLxR6Z1cTAg6+3Gka6IjbUb8GKVU8fOh9fNcWGGWXaoLnzJ/+ 77f/NRAUXxobO5+9bWRYZqSGm26XoQC7hn9Gql6qggzuE33njmOArd1ZoI507vVe0MsV Pz/ZSjteFAvPUqekjNXOGoODWvFXxajR765KY= Received: by 10.42.97.132 with SMTP id o4mr6612866icn.59.1309788499580; Mon, 04 Jul 2011 07:08:19 -0700 (PDT) Received: from DHTABLET ([216.16.242.198]) by mx.google.com with ESMTPS id a9sm6499456icy.18.2011.07.04.07.08.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 07:08:18 -0700 (PDT) From: "Dan Hendry" To: References: <9D80595B-107A-4EDD-9347-70DE5067E65C@zfabrik.de> In-Reply-To: Subject: RE: How to scale Cassandra? Date: Mon, 4 Jul 2011 10:08:16 -0400 Message-ID: <4e11c952.09a32a0a.5ff3.7e8f@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01CC3A32.4B9985B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw6MScOu5xhU+iwTGy5ye3iNOHJNAAIg5hw Content-Language: en-ca This is a multi-part message in MIME format. ------=_NextPart_000_0076_01CC3A32.4B9985B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Moving nodes does not result in downtime provide you use proper replication factors and read/write consistencies. The typical recommendation is RF=3 and QUORUM reads/writes. Dan From: Paul Loy [mailto:keteracel@gmail.com] Sent: July-04-11 5:59 To: user@cassandra.apache.org Subject: Re: How to scale Cassandra? That's basically how I understand it. However, I think it gets better with larger clusters as the proportion of the ring you move around at any time is much lower. On Mon, Jul 4, 2011 at 10:54 AM, Subscriber wrote: Hi there, I read a lot of Cassandra's high scalability feature: allowing seamless addition of nodes, no downtime etc. But I wonder how one will do this in practice in an operational system. In the system we're going to implement we're expecting a huge number of writes with uniformly distributed keys (the keys are given and cannot be generated). That means using RandomPartitioner will (more or less) result in the same work-load per node as any other OrderPreservePartitioner - right? But how do you scale a (more or less) balanced Cassandra cluster? I think that in the end you always have to double the number of nodes (adding just a handful of nodes disburdens only the split regions, the work-load of untouched regions will grow with unchanged speed). This seems to be ok for small clusters. But what do you do with when you have several 100s of nodes in your cluster? It seems to me that a balanced cluster is a bless for performance but a curse for scalability... What are the alternatives? One could re-distribute the token ranges, but this would cause downtimes (AFAIK); not an option! Is there anything that I didn't understand or do I miss something else? Is the only left strategy to make sure that the cluster grows unbalanced so one can add nodes to the hotspots? However in this case you have to make sure that this strategy is lasting. Could be too optimistic... Best Regards Udo -- --------------------------------------------- Paul Loy paul@keteracel.com http://uk.linkedin.com/in/paulloy No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.901 / Virus Database: 271.1.1/3743 - Release Date: 07/04/11 02:35:00 ------=_NextPart_000_0076_01CC3A32.4B9985B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Moving nodes does not result in downtime provide you use proper = replication factors and read/write consistencies. The typical = recommendation is RF=3D3 and QUORUM = reads/writes.

 

Dan

 

From:= Paul Loy = [mailto:keteracel@gmail.com]
Sent: July-04-11 = 5:59
To: user@cassandra.apache.org
Subject: Re: How = to scale Cassandra?

 

That's basically how I understand = it.

However, I think it gets better with larger clusters as the = proportion of the ring you move around at any time is much = lower.

On Mon, Jul 4, 2011 at = 10:54 AM, Subscriber <subscriber@zfabrik.de> = wrote:

Hi there,

I read a lot = of Cassandra's high scalability feature: allowing seamless addition of = nodes, no downtime etc.
But I wonder how one will do this in practice = in an operational system.

In the system we're going to implement = we're expecting a huge number of writes with uniformly distributed = keys
(the keys are given and cannot be generated). That means using = RandomPartitioner will (more or less) result in
the same work-load = per node as any other OrderPreservePartitioner - right?

But how = do you scale a (more or less) balanced Cassandra cluster? I think that = in the end
you always have to double the number of nodes (adding just = a handful of nodes disburdens only the split regions, the
work-load = of untouched regions will grow with unchanged speed).

This seems = to be ok for small clusters. But what do you do with when you have = several 100s of nodes in your cluster?
It seems to me that a balanced = cluster is a bless for performance but a curse for = scalability...

What are the alternatives? One could re-distribute = the token ranges, but this would cause
downtimes (AFAIK); not an = option!

Is there anything that I didn't understand or do I miss = something else? Is the only left strategy to make sure that
the = cluster grows unbalanced so one can add nodes to the hotspots? However = in this case you have to make sure
that this strategy is lasting. = Could be too optimistic...

Best = Regards
Udo




-- =
---------------------------------------------
Paul Loy
paul@keteracel.com
http://uk.linkedin.com/in/paulloy

No virus = found in this incoming message.
Checked by AVG - = www.avg.com
Version: 9.0.901 / Virus Database: 271.1.1/3743 - Release = Date: 07/04/11 02:35:00

------=_NextPart_000_0076_01CC3A32.4B9985B0--