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 CE3EA9C6F for ; Thu, 9 Feb 2012 19:32:29 +0000 (UTC) Received: (qmail 76185 invoked by uid 500); 9 Feb 2012 19:32:27 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 76099 invoked by uid 500); 9 Feb 2012 19:32:26 -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 76091 invoked by uid 99); 9 Feb 2012 19:32:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Feb 2012 19:32:26 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mccloud35@gmail.com designates 209.85.213.172 as permitted sender) Received: from [209.85.213.172] (HELO mail-yx0-f172.google.com) (209.85.213.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Feb 2012 19:32:20 +0000 Received: by yenm3 with SMTP id m3so1271328yen.31 for ; Thu, 09 Feb 2012 11:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NaO01letC4YB48id/PUGZcB9Ji3HYOzqbddidraMj9w=; b=cO2MAfZq/7Vl5a7mldThU1dxlNc/gZHck4/NZcgqL0Y2mpQtiaNwMNUfQk4svixVhw chJ/ur0s4CK99xilNh4lXu09wyP+AKRdhrBwfAsUb31pvFTVnTVAC2woQGr8zr98zlM0 6cuehyhwQyT38Ls/WjxRZNpG9JS7yaVBlht/U= MIME-Version: 1.0 Received: by 10.101.175.4 with SMTP id c4mr1369468anp.84.1328815919757; Thu, 09 Feb 2012 11:31:59 -0800 (PST) Received: by 10.236.177.4 with HTTP; Thu, 9 Feb 2012 11:31:59 -0800 (PST) In-Reply-To: References: <2608CD6D-332E-47E5-B625-C8FB41EAC1ED@thelastpickle.com> Date: Fri, 10 Feb 2012 01:01:59 +0530 Message-ID: Subject: Re: Tips for using OrderedPartitioner From: Tharindu Mathew To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=00504501405ade78e404b88d106f X-Virus-Checked: Checked by ClamAV on apache.org --00504501405ade78e404b88d106f Content-Type: text/plain; charset=ISO-8859-1 That sounds like writing a DB... indexing the index row.... :) By making the keys uniform.... Do you mean like keep the initial X characters the same or the last Y the same... Could you elaborate, please? Also, if there's hot spot is there any way out of it, other than restarting from scratch... On Tue, Jan 24, 2012 at 3:50 PM, R. Verlangen wrote: > If you would like to index your rows in an "index-row", you could also > choose for indexing the "index-rows". This will scale up for any needs and > create a tree structure. > > > 2012/1/24 aaron morton > >> Nothing I can thin of other than making the keys uniform. >> >> Having a single index row with the RP can be a pain. Is there a way to >> partition it ? >> >> Cheers >> >> >> ----------------- >> Aaron Morton >> Freelance Developer >> @aaronmorton >> http://www.thelastpickle.com >> >> On 23/01/2012, at 11:42 PM, Tharindu Mathew wrote: >> >> Hi, >> >> We use Cassandra in a way we always want to range slice queries. Because, >> of the tendency to create hotspots with OrderedPartioner we decided to use >> RandomPartitioner. Then we would use, a row as an index row, holding values >> of the other row keys of the CF. >> >> I feel this has become a burden and would like to move to an >> OrderedPartioner to avoid this work around. The index row workaround which >> has become cumbersome when we query the data store. >> >> Is there any tips we can follow to allow for lesser amount of hot spots? >> >> -- >> Regards, >> >> Tharindu >> >> blog: http://mackiemathew.com/ >> >> >> > -- Regards, Tharindu blog: http://mackiemathew.com/ --00504501405ade78e404b88d106f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That sounds like writing a DB... indexing the index row.... :)

By ma= king the keys uniform.... Do you mean like keep the initial X characters th= e same or the last Y the same... Could you elaborate, please?

Also, = if there's hot spot is there any way out of it, other than restarting f= rom scratch...

On Tue, Jan 24, 2012 at 3:50 PM, R. Verlange= n <robin@us2.nl>= ; wrote:
If you would like to index your rows in an "index-row", you could= also choose for indexing the "index-rows". This will scale up fo= r any needs and create a tree structure.


2012/1/24 aaron morton <aaron@thelastpickle.com>
Nothing I can thin of other than m= aking the keys uniform.

Having a single index row = with the RP can be a pain. Is there a way to partition it ?

Cheers


<= div style=3D"word-wrap:break-word">
-----------------
Aaron M= orton
Freelance Developer
@aaronmorton

On 23/01/2012, at 11:42 PM, Tharindu Mathew wrote:

<= blockquote type=3D"cite">Hi,

We use Cassandra in a way w= e always want to range slice queries. Because, of the tendency to create ho= tspots with OrderedPartioner we decided to use RandomPartitioner. Then we w= ould use, a row as an index row, holding values of the other row keys of th= e CF.

I feel this has become a burden and would like to move = to an OrderedPartioner to avoid this work around. The index row workaround = which has become cumbersome when we query the data store.

Is there any tips we can follow to allow for lesser amount of ho= t spots?

--
Regards,

Tharindu






--
Regards,
Tharindu


--00504501405ade78e404b88d106f--