incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan McCall <n...@vervewireless.com>
Subject Re: Using column plus value or only column?
Date Tue, 02 Feb 2010 23:55:19 GMT
Erik,
You can do an inverse with 'reversed=true' in SliceRange as part of
the SlicePredicate for both get_slice or get_range_slice. I have not
tried reverse=true 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 same
> 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 reverse 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 using 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 : {
>> >   sort_row_1 : {
>> >        sortKey1 : { col1:val1, col2:val2 },
>> >        sortKey2 : { col1:val3, col2:val4 }
>> >   }
>> > }
>> >
>> > 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.com>
>> > wrote:
>> >> Thanks Nate for the example.
>> >>
>> >> I was thinking more a long the lines of something like:
>> >>
>> >> If you have a family
>> >>
>> >> Data : {
>> >>   row1 : {
>> >>     col1:val1,
>> >>   row2 : {
>> >>     col1:val2,
>> >>     ...
>> >>   }
>> >> }
>> >>
>> >>
>> >> Using
>> >> Sorts : {
>> >>   sort_row : {
>> >>     sortKey1_datarow1: [],
>> >>     sortKey2_datarow2: []
>> >>   }
>> >> }
>> >>
>> >> Instead of
>> >> Sorts : {
>> >>   sort_row : {
>> >>     sortKey1: datarow1,
>> >>     sortKey2: datarow2
>> >>   }
>> >> }
>> >>
>> >> If that makes any sense?
>> >>
>> >> --
>> >> Regards Erik
>> >>
>> >
>
>
>
> --
> Regards Erik
>

Mime
View raw message