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 D80D19C28 for ; Thu, 26 Jan 2012 20:49:09 +0000 (UTC) Received: (qmail 23769 invoked by uid 500); 26 Jan 2012 20:49:07 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 23637 invoked by uid 500); 26 Jan 2012 20:49:06 -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 23623 invoked by uid 99); 26 Jan 2012 20:49:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jan 2012 20:49:06 +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; Thu, 26 Jan 2012 20:48:59 +0000 Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 8472B3A406D for ; Thu, 26 Jan 2012 12:48:37 -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=DKTbTNILZs NkCOthZzquD6hN8oBwvmtbmNJ09P0p6Glq3N5Op4Du/ensmRPNaecK0p0ex3daWv Zvx6/bDS4pdB5mZqn780WibtrMvR6bShpAlB1bMdFe/crx2J9fGIMo9hEvAh6Wj0 Ae2/opu7FUT2mSsAKiR58tddL8qK1vtoQ= 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=WXrtc0eQ0wVEa0GN kqnZdjfwsOM=; b=wVIItnYuzMVknPKf95BPOYmm/7m1JK41aNXkKxWdhK9Md1Ng ikDlH385IPZ5Szl0DIAAa8+mc/IPiMoi60oXD3QairsyUP3C0SeX0SVqpP5jxlC+ iSDxSq8Z57jVTfBBKmdUZYTohpmVWEr+m4d+c8Z+n0nypANBixajBDoz0PQ= 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 E01E03A4078 for ; Thu, 26 Jan 2012 12:48:36 -0800 (PST) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_0DC495DE-56D7-4AE9-AF65-5867ACBC1E90" Subject: Re: Mixed random & ordered partitioning? Date: Fri, 27 Jan 2012 09:48:33 +1300 In-Reply-To: <4F210273.1020608@conga.com> To: user@cassandra.apache.org References: <4F210273.1020608@conga.com> Message-Id: <2D5EA63E-570E-43FC-A697-062BF9ED29CC@thelastpickle.com> X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_0DC495DE-56D7-4AE9-AF65-5867ACBC1E90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > What is be the effective difference between hashing the keys myself = and letting the random partitioner do it? This is what the RandomPartitioner calls = https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassand= ra/utils/FBUtilities.java#L209 > Is this advisable? I would try to avoid it. It's going to add to your code complexity and = make it very hard to balance the cluster.=20 Is building an index row an option ? Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 26/01/2012, at 8:36 PM, Todd Fast wrote: > I want to do ranged row queries for a few of my column families, but = best practice seems to be to use the random partitioner. Splitting my = column families between two clusters (one random, one ordered) seems = like a pretty expensive compromise. >=20 > Instead, I'm thinking of using the order-preserving partitioner in my = cluster, but distributing load for most of my column families by hashing = the row keys in my application code. Then, for the few column families = which I need to slice rows, I can just use unhashed keys. >=20 > What is be the effective difference between hashing the keys myself = and letting the random partitioner do it? Is this advisable? >=20 > Thanks, > Todd >=20 --Apple-Mail=_0DC495DE-56D7-4AE9-AF65-5867ACBC1E90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
What is be the effective difference = between hashing the keys myself and letting the random partitioner do = it?
This is what the RandomPartitioner calls

Is this = advisable?
I would try to avoid it. It's going to add = to your code complexity and make it very hard to balance the = cluster. 

Is building an index row an = option ?

Cheers

http://www.thelastpickle.com

On 26/01/2012, at 8:36 PM, Todd Fast wrote:

I = want to do ranged row queries for a few of my column families, but best = practice seems to be to use the random partitioner. Splitting my column = families between two clusters (one random, one ordered) seems like a = pretty expensive compromise.

Instead, I'm thinking of using the = order-preserving partitioner in my cluster, but distributing load for = most of my column families by hashing the row keys in my application = code. Then, for the few column families which I need to slice rows, I = can just use unhashed keys.

What is be the effective difference = between hashing the keys myself and letting the random partitioner do = it? Is this = advisable?

Thanks,
Todd


= --Apple-Mail=_0DC495DE-56D7-4AE9-AF65-5867ACBC1E90--