You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Erik Holstad <er...@gmail.com> on 2010/02/02 18:50:10 UTC
Using column plus value or only column?
Sorry that there are a lot of questions from me this week, just trying to
better understand
the best way to use Cassandra :)
Let us say that you know the length of your key, everything is standardized,
are there people
out there that just tag the value onto the key so that you don't have to pay
the extra overhead
of the second byte[]?
--
Regards Erik
Re: Using column plus value or only column?
Posted by Erik Holstad <er...@gmail.com>.
Don't be silly, thanks a lot for helping me out!
--
Regards Erik
Re: Using column plus value or only column?
Posted by Nathan McCall <na...@vervewireless.com>.
Ok - I was afraid I was going to miss something with the generic
example before - my apologies on that. You cannot impose an order on
keys like that as far as I am aware. I think maintaining a Sort CF as
you had originally is a decent approach.
Cheers,
-Nate
On Tue, Feb 2, 2010 at 4:06 PM, Erik Holstad <er...@gmail.com> wrote:
> Hey Nate!
> What I wanted to do with the get_range_slice was to receive the keys in the
> 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 <na...@vervewireless.com>
> wrote:
>>
>> 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 <er...@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
>> > <je...@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 <na...@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 <er...@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
>> >
>
>
>
> --
> Regards Erik
>
Re: Using column plus value or only column?
Posted by Erik Holstad <er...@gmail.com>.
I don't understand what you mean ;)
Will see what happens when we are done with this first project, will see
if we can get some time to give back.
--
Regards Erik
Re: Using column plus value or only column?
Posted by Jonathan Ellis <jb...@gmail.com>.
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 <er...@gmail.com> wrote:
> Hey Nate!
> What I wanted to do with the get_range_slice was to receive the keys in the
> 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 <na...@vervewireless.com>
> wrote:
>>
>> 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 <er...@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
>> > <je...@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 <na...@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 <er...@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
>> >
>
>
>
> --
> Regards Erik
>
Re: Using column plus value or only column?
Posted by Erik Holstad <er...@gmail.com>.
Hey Nate!
What I wanted to do with the get_range_slice was to receive the keys in the
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 <na...@vervewireless.com>wrote:
> 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 <er...@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 <na...@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 <er...@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
> >
>
--
Regards Erik
Re: Using column plus value or only column?
Posted by Nathan McCall <na...@vervewireless.com>.
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 <er...@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 <je...@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 <na...@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 <er...@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
>
Re: Using column plus value or only column?
Posted by Erik Holstad <er...@gmail.com>.
@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-598correctly 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
<je...@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 <na...@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 <er...@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
Re: Using column plus value or only column?
Posted by Jesse McConnell <je...@gmail.com>.
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 <na...@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 <er...@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
>>
>
Re: Using column plus value or only column?
Posted by Nathan McCall <na...@vervewireless.com>.
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 <er...@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
>
Re: Using column plus value or only column?
Posted by Erik Holstad <er...@gmail.com>.
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
Re: Using column plus value or only column?
Posted by Nathan McCall <na...@vervewireless.com>.
If I understand you correctly, I think I have a decent example. I have
a ColumnFamily which models user preferences for a "site" in our
system:
UserPreferences : {
123_EDD43E57589F12032AF73E23A6AF3F47 : {
favorite_color : red,
...
}
}
I structured it this way because we have a lot of "sites" to which a
user could create preferences for, so the site_id is prepended to the
value of a session_id therefore you always need two pieces of
information to enforce that a given record belongs to a specific
"site". The site_id is always an integer and the session_id is always
a 32 char string so sticking an underscore between them makes
validatable parsing and construction trivial. The bloom filtering
behind the key lookups also make checks for existence extremely fast.
Note: I feel compelled to mention this is not a typical use case that
I think would generally warrant anything outside of an RDBMS. However,
In our system writes to this preference "table" can burst up to
several thousand a second. Thus the need for the predictable write
performance of Cassandra.
Cheers,
Nate
On Tue, Feb 2, 2010 at 9:50 AM, Erik Holstad <er...@gmail.com> wrote:
> Sorry that there are a lot of questions from me this week, just trying to
> better understand
> the best way to use Cassandra :)
>
> Let us say that you know the length of your key, everything is standardized,
> are there people
> out there that just tag the value onto the key so that you don't have to pay
> the extra overhead
> of the second byte[]?
>
> --
> Regards Erik
>