Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jbellis@gmail.com designates
 209.85.219.212 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=VLHbOYjOw5dLN2gBxSWjwPln7AHcrGmDs92eHIxw8RY9EgBXY0aMLmMhacX2v95ePH
         bv9WixE4N2Xvl4xO1rJrLt25/LaFFTOeK3l/EMRj8foIxr51//Jy/0kXN5JYS+l/0WP0
         f63PGaJPqf2nI3CobHnMYPe6q757P7dyVe+hU=
MIME-Version: 1.0
In-Reply-To: <74f4d40b1002021606x1b967eaam1d45455a3dc89579@mail.gmail.com>
References: <74f4d40b1002020950p66e6f9a1hdea1b5cb4b4e1aa2@mail.gmail.com>
	<a17e13e71002021141m6d3c04c5nf204f4302e8bca48@mail.gmail.com>
	<74f4d40b1002021200m5a91b21es3e3a12cd3b80ff0c@mail.gmail.com>
	<a17e13e71002021430j2ec56dc9ka59d8360b5736a78@mail.gmail.com>
	<a43524d01002021439k40e8de9x9d6935d8b2542f95@mail.gmail.com>
	<74f4d40b1002021502q3b8034dfu97aef578d39fbc74@mail.gmail.com>
	<a17e13e71002021555q76c8d27cia57ea27a76578a4c@mail.gmail.com>
	<74f4d40b1002021606x1b967eaam1d45455a3dc89579@mail.gmail.com>
From: Jonathan Ellis <jbellis@gmail.com>
Date: Tue, 2 Feb 2010 18:35:20 -0600
Message-ID: <e06563881002021635q44a751e8n7769eaf191263427@mail.gmail.com>
Subject: Re: Using column plus value or only column?
To: cassandra-user@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Right, we don't currently support scanning rows in reverse order, but
that is only because nobody has wanted it badly enough to code it. :)

On Tue, Feb 2, 2010 at 6:06 PM, Erik Holstad <erikholstad@gmail.com> wrote:
> Hey Nate!
> What I wanted to do with the get_range_slice was to receive the keys in t=
he
> inverted order, so that I could so offset limit queries on key ranges in
> reverse
> order. Like you said, this can be done for both columns and super columns
> with
> help of the SliceRange, but not on keys afaik, but maybe there is a way?
>
> Thanks Erik
>
>
> On Tue, Feb 2, 2010 at 3:55 PM, Nathan McCall <nate@vervewireless.com>
> wrote:
>>
>> Erik,
>> You can do an inverse with 'reversed=3Dtrue' in SliceRange as part of
>> the SlicePredicate for both get_slice or get_range_slice. I have not
>> tried reverse=3Dtrue on SuperColumn results, but I dont think there is
>> any difference there - what can't be changed is how things are ordered
>> but direction can go either way (If I am wrong on this, somebody
>> please correct me).
>>
>> http://issues.apache.org/jira/browse/CASSANDRA-598 has not been on my
>> radar as I dont have anything reporting-ish like you describe with
>> SuperColumns (yet). I will defer to more experienced folks with this.
>>
>> Regards,
>> -Nate
>>
>>
>> On Tue, Feb 2, 2010 at 3:02 PM, Erik Holstad <erikholstad@gmail.com>
>> wrote:
>> > @Nathan
>> > So what I'm planning to do is to store multiple sort orders for the sa=
me
>> > data, where they all use the
>> > same data table just fetches it in different orders, so to say. I want
>> > to be
>> > able to rad the different sort
>> > orders from the front and from the back to get both regular and revers=
e
>> > sort
>> > order.
>> >
>> > With your approach using super columns you would need to replicate all
>> > data,
>> > right?
>> >
>> > And if I understand http://issues.apache.org/jira/browse/CASSANDRA-598
>> > correctly you would need to
>> > read the whole thing before you can limit the results handed back to
>> > you.
>> >
>> > In regards to the two calls get_slice and get_range_slice, the way I
>> > understand it is that you hand
>> > the second one an optional start and stop key plus a limit, to get a
>> > range
>> > of keys/rows. I was planning
>> > to use this call together with the OPP, but are thinking about not usi=
ng
>> > it
>> > since there is no way to do
>> > an inverse scan, right?
>> >
>> > Thanks a lot
>> > Erik
>> >
>> >
>> > On Tue, Feb 2, 2010 at 2:39 PM, Jesse McConnell
>> > <jesse.mcconnell@gmail.com>
>> > wrote:
>> >>
>> >> infinite is a bit of a bold claim....
>> >>
>> >> by my understanding you are bound by the memory of the jvm as all of
>> >> the content of a key/row currently needs to fit in memory for
>> >> compaction, which includes columns and supercolumns for given key/row=
.
>> >>
>> >> if you are going to run into those scenarios then some sort of
>> >> sharding on the keys is required, afaict
>> >>
>> >> cheers,
>> >> jesse
>> >>
>> >> --
>> >> jesse mcconnell
>> >> jesse.mcconnell@gmail.com
>> >>
>> >>
>> >>
>> >> On Tue, Feb 2, 2010 at 16:30, Nathan McCall <nate@vervewireless.com>
>> >> wrote:
>> >> > Erik,
>> >> > Sure, you could and depending on the workload, that might be quite
>> >> > efficient for small pieces of data. However, this also sounds like
>> >> > something that might be better addressed with the addition of a
>> >> > SuperColumn on "Sorts" and getting rid of "Data" altogether:
>> >> >
>> >> > Sorts : {
>> >> > =A0 sort_row_1 : {
>> >> > =A0 =A0 =A0 =A0sortKey1 : { col1:val1, col2:val2 },
>> >> > =A0 =A0 =A0 =A0sortKey2 : { col1:val3, col2:val4 }
>> >> > =A0 }
>> >> > }
>> >> >
>> >> > You can have an infinite number of SuperColumns for a key, but make
>> >> > sure you understand get_slice vs. get_range_slice before you commit
>> >> > to
>> >> > a design. Hopefully I understood your example correctly, if not, do
>> >> > you have anything more concrete?
>> >> >
>> >> > Cheers,
>> >> > -Nate
>> >> >
>> >> >
>> >> > On Tue, Feb 2, 2010 at 12:00 PM, Erik Holstad <erikholstad@gmail.co=
m>
>> >> > wrote:
>> >> >> Thanks Nate for the example.
>> >> >>
>> >> >> I was thinking more a long the lines of something like:
>> >> >>
>> >> >> If you have a family
>> >> >>
>> >> >> Data : {
>> >> >> =A0 row1 : {
>> >> >> =A0=A0=A0 col1:val1,
>> >> >> =A0 row2 : {
>> >> >> =A0=A0=A0 col1:val2,
>> >> >> =A0=A0=A0 ...
>> >> >> =A0 }
>> >> >> }
>> >> >>
>> >> >>
>> >> >> Using
>> >> >> Sorts : {
>> >> >> =A0 sort_row : {
>> >> >> =A0=A0=A0 sortKey1_datarow1: [],
>> >> >> =A0=A0=A0 sortKey2_datarow2: []
>> >> >> =A0 }
>> >> >> }
>> >> >>
>> >> >> Instead of
>> >> >> Sorts : {
>> >> >> =A0 sort_row : {
>> >> >> =A0=A0=A0 sortKey1: datarow1,
>> >> >> =A0=A0=A0 sortKey2: datarow2
>> >> >> =A0 }
>> >> >> }
>> >> >>
>> >> >> If that makes any sense?
>> >> >>
>> >> >> --
>> >> >> Regards Erik
>> >> >>
>> >> >
>> >
>> >
>> >
>> > --
>> > Regards Erik
>> >
>
>
>
> --
> Regards Erik
>