Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 39214 invoked from network); 9 Jun 2010 10:56:43 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 9 Jun 2010 10:56:43 -0000 Received: (qmail 95846 invoked by uid 500); 9 Jun 2010 10:56:41 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 95605 invoked by uid 500); 9 Jun 2010 10:56:41 -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 95597 invoked by uid 99); 9 Jun 2010 10:56:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Jun 2010 10:56:41 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ben324@gmail.com designates 209.85.212.44 as permitted sender) Received: from [209.85.212.44] (HELO mail-vw0-f44.google.com) (209.85.212.44) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Jun 2010 10:56:35 +0000 Received: by vws9 with SMTP id 9so1401655vws.31 for ; Wed, 09 Jun 2010 03:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=jDKiL0XuGGN88acojxcXngU6gWIpkIJN9uhv3voo8VM=; b=lN4QRut8PiQtpfkiBjBfsF9zMTPrHGmGFflRcXOJvUzTWfl1q9U0LAyiTzkcq3Z5ur iGWytfexbraEF4A/Qi0Oa94XMUyrtp2IFucUV7Xk0SOrWZ5vI9GZ43c/SWeLfrIRAMA3 yBxCWoqx6BfFHqsBGf2JIqadoeXYExXiAlaP4= 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:content-transfer-encoding; b=h5MzGPRcGV1pKiHgp2fWVCcs2UdvfbUyjVEB/9LHTrqAbBOiQwZR9eJVV3RKiOMGJ3 mzpvY3uFWdQ/95jpQXlOQNNhQsXnSlijzb5nKfYfG+cHClZaWMqCKKmehUrli2mHY+YF HmkWoqrZ/vsAWEQVWIfALi3GCbtwYYsYOg6cc= MIME-Version: 1.0 Received: by 10.224.27.145 with SMTP id i17mr1080181qac.180.1276080974132; Wed, 09 Jun 2010 03:56:14 -0700 (PDT) Received: by 10.229.142.12 with HTTP; Wed, 9 Jun 2010 03:56:14 -0700 (PDT) In-Reply-To: <201006091026281454917@sina.com> References: <1OJmvq-0003eg-Sh@mail.eleven.de> <1OJnIA-0004R3-Ik@mail.eleven.de> <201006091026281454917@sina.com> Date: Wed, 9 Jun 2010 06:56:14 -0400 Message-ID: Subject: Re: Re: Range search on keys not working? From: Ben Browning To: user@cassandra.apache.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org OPP stands for Order-Preserving Partitioner. For more information on partitioners, look here: http://wiki.apache.org/cassandra/StorageConfiguration#Partitioner To do key range slices that use both start and finish parameters and retrieve keys in-order, you need to use an ordered partitioner - either the built-in OPP or your own custom one. Ben On Tue, Jun 8, 2010 at 10:26 PM, sina wrote: > what's the mean of opp? And How can i make the "start" and "finish" usefu= l > and make sense? > > > 2010-06-09 > ________________________________ > 9527 > ________________________________ > =B7=A2=BC=FE=C8=CB=A3=BA Ben Browning > =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2010-06-02 21:08:57 > =CA=D5=BC=FE=C8=CB=A3=BA user > =B3=AD=CB=CD=A3=BA > =D6=F7=CC=E2=A3=BA Re: Range search on keys not working? > They exist because when using OPP they are useful and make sense. > On Wed, Jun 2, 2010 at 8:59 AM, David Boxenhorn wrote= : >> So why do the "start" and "finish" range parameters exist? >> >> On Wed, Jun 2, 2010 at 3:53 PM, Ben Browning wrote: >>> >>> Martin, >>> >>> On Wed, Jun 2, 2010 at 8:34 AM, Dr. Martin Grabm=A8=B9ller >>> wrote: >>> > I think you can specify an end key, but it should be a key which does >>> > exist >>> > in your column family. >>> >>> >>> Logically, it doesn't make sense to ever specify an end key with >>> random partitioner. If you specified a start key of "aaa" and and end >>> key of "aac" you might get back as results "aaa", "zfc", "hik", etc. >>> And, even if you have a key of "aab" it might not show up. Key ranges >>> only make sense with order-preserving partitioner. The only time to >>> ever use a key range with random partitioner is when you want to >>> iterate over all keys in the CF. >>> >>> Ben >>> >>> >>> > But maybe I'm off the track here and someone else here knows more abo= ut >>> > this >>> > key range stuff. >>> > >>> > Martin >>> > >>> > ________________________________ >>> > From: David Boxenhorn [mailto:david@lookin2.com] >>> > Sent: Wednesday, June 02, 2010 2:30 PM >>> > To: user@cassandra.apache.org >>> > Subject: Re: Range search on keys not working? >>> > >>> > In other words, I should check the values as I iterate, and stop >>> > iterating >>> > when I get out of range? >>> > >>> > I'll try that! >>> > >>> > On Wed, Jun 2, 2010 at 3:15 PM, Dr. Martin Grabm=A8=B9ller >>> > wrote: >>> >> >>> >> When not using OOP, you should not use something like 'CATEGORY/' as >>> >> the >>> >> end key. >>> >> Use the empty string as the end key and limit the number of returned >>> >> keys, >>> >> as you did with >>> >> the 'max' value. >>> >> >>> >> If I understand correctly, the end key is used to generate an end to= ken >>> >> by >>> >> hashing it, and >>> >> there is not the same correspondence between 'CATEGORY' and 'CATEGOR= Y/' >>> >> as >>> >> for >>> >> hash('CATEGORY') and hash('CATEGORY/'). >>> >> >>> >> At least, this was the explanation I gave myself when I had the same >>> >> problem. >>> >> >>> >> The solution is to iterate through the keys by always using the last >>> >> key >>> >> returned as the >>> >> start key for the next call to get_range_slices, and the to drop the >>> >> first >>> >> element from >>> >> the result. >>> >> >>> >> HTH, >>> >> Martin >>> >> >>> >> ________________________________ >>> >> From: David Boxenhorn [mailto:david@lookin2.com] >>> >> Sent: Wednesday, June 02, 2010 2:01 PM >>> >> To: user@cassandra.apache.org >>> >> Subject: Re: Range search on keys not working? >>> >> >>> >> The previous thread where we discussed this is called, "key is sorte= d?" >>> >> >>> >> >>> >> On Wed, Jun 2, 2010 at 2:56 PM, David Boxenhorn >>> >> wrote: >>> >>> >>> >>> I'm not using OPP. But I was assured on earlier threads (I asked >>> >>> several >>> >>> times to be sure) that it would work as stated below: the results >>> >>> would not >>> >>> be ordered, but they would be correct. >>> >>> >>> >>> On Wed, Jun 2, 2010 at 2:51 PM, Torsten Curdt >>> >>> wrote: >>> >>>> >>> >>>> Sounds like you are not using an order preserving partitioner? >>> >>>> >>> >>>> On Wed, Jun 2, 2010 at 13:48, David Boxenhorn >>> >>>> wrote: >>> >>>> > Range search on keys is not working for me. I was assured in >>> >>>> > earlier >>> >>>> > threads >>> >>>> > that range search would work, but the results would not be order= ed. >>> >>>> > >>> >>>> > I'm trying to get all the rows that start with "CATEGORY." >>> >>>> > >>> >>>> > I'm doing: >>> >>>> > >>> >>>> > String start =3D "CATEGORY."; >>> >>>> > . >>> >>>> > . >>> >>>> > . >>> >>>> > keyspace.getSuperRangeSlice(columnParent, slicePredicate, start, >>> >>>> > "CATEGORY/", max) >>> >>>> > . >>> >>>> > . >>> >>>> > . >>> >>>> > >>> >>>> > in a loop, setting start to the last key each time - but I'm >>> >>>> > getting >>> >>>> > rows >>> >>>> > that don't start with "CATEGORY."!! >>> >>>> > >>> >>>> > How do I get all rows that start with "CATEGORY."? >>> >>> >>> >> >>> > >>> > >> >> > __________ Information from ESET NOD32 Antivirus, version of virus signat= ure database 5164 (20100601) __________ > The message was checked by ESET NOD32 Antivirus. > http://www.eset.com