From cassandra-user-return-735-apmail-incubator-cassandra-user-archive=incubator.apache.org@incubator.apache.org Thu Oct 01 16:41:52 2009 Return-Path: Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org Received: (qmail 55368 invoked from network); 1 Oct 2009 16:41:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Oct 2009 16:41:52 -0000 Received: (qmail 68783 invoked by uid 500); 1 Oct 2009 16:41:51 -0000 Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org Received: (qmail 68765 invoked by uid 500); 1 Oct 2009 16:41:51 -0000 Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-user@incubator.apache.org Delivered-To: mailing list cassandra-user@incubator.apache.org Received: (qmail 68756 invoked by uid 99); 1 Oct 2009 16:41:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 16:41:51 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: unknown (nike.apache.org: error in processing during lookup of junrao@almaden.ibm.com) Received: from [32.97.182.137] (HELO e7.ny.us.ibm.com) (32.97.182.137) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 16:41:39 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n91Gco8C001184 for ; Thu, 1 Oct 2009 12:38:50 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n91GfIPK231326 for ; Thu, 1 Oct 2009 12:41:18 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n91GfIY5018007 for ; Thu, 1 Oct 2009 12:41:18 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n91GfIgp017995 for ; Thu, 1 Oct 2009 12:41:18 -0400 In-Reply-To: <23b1e84e0910010926w65e08b7dke62d6c615e441645@mail.gmail.com> References: <23b1e84e0910010926w65e08b7dke62d6c615e441645@mail.gmail.com> Subject: Re: distributing tokens equally along the key distribution space X-KeepSent: 7D3F645E:654652B3-88257642:005B4858; type=4; name=$KeepSent To: cassandra-user@incubator.apache.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Jun Rao Date: Thu, 1 Oct 2009 09:41:11 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 8.5|December 05, 2008) at 10/01/2009 12:41:17 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBFCD1DFC8CEC88f9e8a93df938690918c07BBFCD1DFC8CEC8" Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org --0__=07BBFCD1DFC8CEC88f9e8a93df938690918c07BBFCD1DFC8CEC8 Content-type: text/plain; charset=US-ASCII For #1, the random tokens are 128bits positive bigints. So, you can generate tokens evenly btw [0, 2^127-1] and set them on each node using InitialToken in storage-conf.xml. Jun IBM Almaden Research Center K55/B1, 650 Harry Road, San Jose, CA 95120-6099 junrao@almaden.ibm.com Igor Katkov wrote on 10/01/2009 09:26:45 AM: > [image removed] > > distributing tokens equally along the key distribution space > > Igor Katkov > > to: > > cassandra-user > > 10/01/2009 09:28 AM > > Please respond to cassandra-user > > Hi, > > Question#1: > How to manually select tokens to force equal spacing of tokens > around the hash space? > If RandomPartitioner is used a token is a BigInteger, so there are > no [0, Max value] interval to select token values from. > If everything is left to defaults, a token is a random number (hash > of GUID) so these 10 generated tokens will not be evenly spaced on the ring. > Suppose I have X nodes, what would be correct token values? > > Question#2: > Let's assume that #1 was resolved somehow and key distribution is > more or less even. > A new node "C" joins the cluster. It's token falls somewhere between > two other tokens on the ring (from nodes "A" and "B" clockwise- > ordered). From now on "C" is responsible for a portion of data that > used to exclusively belong to "B". > a. Cassandra v.0.4 will not automatically transfer this data to "C" will it? > b. Do all reads to these keys fail? > c. What happens with the data reference by these keys on "B"? It > will never be accessed there, therefor it becomes garbage. Since > there are to GC will it stick forever? > d. What happens to replicas of these keys? --0__=07BBFCD1DFC8CEC88f9e8a93df938690918c07BBFCD1DFC8CEC8 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

For #1, the random tokens are 128bits positive bigints. So, you can generate tokens evenly btw [0, 2^127-1] and set them on each node using InitialToken in storage-conf.xml.

Jun
IBM Almaden Research Center
K55/B1, 650 Harry Road, San Jose, CA 95120-6099

junrao@almaden.ibm.com


Igor Katkov <ikatkov@gmail.com> wrote on 10/01/2009 09:26:45 AM:

> [image removed]

>
> distributing tokens equally along the key distribution space

>
> Igor Katkov

>
> to:

>
> cassandra-user

>
> 10/01/2009 09:28 AM

>
> Please respond to cassandra-user

>
> Hi,
>
> Question#1:
> How to manually select tokens to force equal spacing of tokens
> around the hash space?
> If RandomPartitioner is used a token is a BigInteger, so there are
> no [0, Max value] interval to select token values from.
> If everything is left to defaults, a token is a random number (hash
> of GUID) so these 10 generated tokens will not be evenly spaced on the ring.
> Suppose I have X nodes, what would be correct token values?
>
> Question#2:
> Let's assume that #1 was resolved somehow and key distribution is
> more or less even.
> A new node "C" joins the cluster. It's token falls somewhere between
> two other tokens on the ring (from nodes "A" and "B" clockwise-
> ordered). From now on "C" is responsible for a portion of data that
> used to exclusively belong to "B".
> a. Cassandra v.0.4 will not automatically transfer this data to "C" will it?
> b. Do all reads to these keys fail?
> c. What happens with the data reference by these keys on "B"? It
> will never be accessed there, therefor it becomes garbage. Since
> there are to GC will it stick forever?
> d. What happens to replicas of these keys?
--0__=07BBFCD1DFC8CEC88f9e8a93df938690918c07BBFCD1DFC8CEC8--