Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of markxr@gmail.com designates
 209.85.218.222 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=OiGOJNxNTgRR7i9BzwDAsUnZiUFuXcShr3tFMQn4x5+4TTSPUdPkxZk28cKqkI7PyW
         u4T4utYtSmONUE8PtkrgTn5TZd8ClRTDWHnxQnOpCSi6KWcrG4YQ9ZkRcC26KEne8NGu
         uryYw1JPeJhDf4ajsjBja8/T44WdDy+lNjYK8=
MIME-Version: 1.0
In-Reply-To: <j2xfd5ddcb11004251818y30686b7cx3ebb17d07b2bc312@mail.gmail.com>
References: <j2xfd5ddcb11004251818y30686b7cx3ebb17d07b2bc312@mail.gmail.com>
Date: Mon, 26 Apr 2010 10:17:22 +0000
Message-ID: <s2jff1a07b81004260317qecbf63c7x46316120625a4135@mail.gmail.com>
Subject: Re: when i use the OrderPreservingPartition, the load is very
	imbalance
From: Mark Robson <markxr@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=00032555404a2c414e0485211560

--00032555404a2c414e0485211560
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 26 April 2010 01:18, =E5=88=98=E5=85=B5=E5=85=B5 <rucbing@gmail.com> wro=
te:

> i do some INSERT ,because i will do some scan operations, i use the
> OrderPreservingPartition method.
>
> the state of the cluster is showed below.
>
> as i predicated the load is very imbalance


I think the solution to this would be to choose your nodes' tokens wisely
before you start inserting data, and if possible, modify the keys to split
them better between the nodes.

For example, if your key has two parts, one of which you want to range scan=
,
another which you don't. Say you have customer_id and a timestamp. The
customer ID does not need to be range scanned, so you can hash it into a he=
x
value (say), then append the timestamp (in a lexically sortable way of
course). So you'd end up with keys like

HHHH-0012345-0001234567890

Where HHHH is a hash of the customer ID, 0012345 is the customer ID, and th=
e
rest is a timestamp.

You'd be able to do a time range scan by using the known prefixes, and
distributing your nodes equally from 0000 to ffff would result in fairly
even data (provided you don't have a very small number of very large
customers).

Mark

--00032555404a2c414e0485211560
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On 26 April 2010 01:18, =E5=88=98=E5=85=B5=E5=85=
=B5 <span dir=3D"ltr">&lt;<a href=3D"mailto:rucbing@gmail.com">rucbing@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
i do some INSERT ,because i will do some scan operations, i use the OrderPr=
eservingPartition method.<br><br>the state of the cluster is showed below.<=
br><br>as i predicated the load is very imbalance</blockquote><div><br>
</div><div><br></div><div>I think the solution to this would be to choose y=
our nodes&#39; tokens wisely before you start inserting data, and if possib=
le, modify the keys to split them better between the nodes.</div><div><br>
</div><div>For example, if your key has two parts, one of which you want to=
 range scan, another which you don&#39;t. Say you have customer_id and a ti=
mestamp. The customer ID does not need to be range scanned, so you can hash=
 it into a hex value (say), then append the timestamp (in a lexically sorta=
ble way of course). So you&#39;d end up with keys like=C2=A0</div>
<div><br></div><div>HHHH-0012345-0001234567890</div><div><br></div><div>Whe=
re HHHH is a hash of the customer ID,=C2=A00012345 is the customer ID, and =
the rest is a timestamp.</div><div><br></div><div>You&#39;d be able to do a=
 time range scan by using the known prefixes, and distributing your nodes e=
qually from 0000 to ffff would result in fairly even data (provided you don=
&#39;t have a very small number of very large customers).</div>
<div><br></div><div>Mark</div></div>

--00032555404a2c414e0485211560--