incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Software Dev <static.void....@gmail.com>
Subject Re: Columns limit
Date Fri, 06 Aug 2010 22:34:32 GMT
I'm a little retarded. Can you explain this a little more in depth? What you
mean by "index rows named...". Do you mean create a separate ColumnFamily?

On Sat, Jul 31, 2010 at 9:32 PM, Benjamin Black <b@b3k.us> wrote:

> Have the TimeUUID as the key, and then index rows named for the time
> intervals, each containing columns with TimeUUID names giving the data
> in those intervals.
>
> On Sat, Jul 31, 2010 at 5:13 PM, Mark <static.void.dev@gmail.com> wrote:
> > So have the TimeUUID as the key?
> >
> > SearchLogs : {
> >    TimeUUID_1 : { metadata goes here},
> >    TimeUUID_2 : { metadata goes here},
> >    TimeUUID_3 : { metadata goes here},
> >    ...
> > }
> >
> > On 7/31/10 3:42 PM, Benjamin Black wrote:
> >>
> >> The proper way to handle this is to have a row per time interval such
> >> that the number of columns per row is constrained.
> >>
> >> On Thu, Jul 29, 2010 at 2:39 PM, Mark<static.void.dev@gmail.com>
>  wrote:
> >>
> >>>
> >>> Is there any limitations on the number of columns a row can have? Does
> >>> all
> >>> the day for a single key need to reside on a single host? If so,
> wouldn't
> >>> that mean there is an implicit limit on the number of columns one can
> >>> have... ie the disk size of that machine.
> >>>
> >>> What is the proper way to handle timelines in this matter. For example
> >>> lets
> >>> say I wanted to store all user searches in a super column.
> >>>
> >>> <ColumnFamily Name="SearchLogs"
> >>>                    ColumnType="Super"
> >>>                    CompareWith="TimeUUIDType"
> >>>                    CompareSubcolumnsWith="BytesType"/>
> >>>
> >>> Which results in a structure as follows
> >>> {
> >>>   SearchLogs : {
> >>>       "foo" : {
> >>>            timeuuid_1 : { metadata goes here}
> >>>            timeuuid_2: { metadata goes here}
> >>>       },
> >>>       "bar" : {
> >>>            timeuuid_1 : { metadata goes here}
> >>>            timeuuid_2: { metadata goes here}
> >>>       }
> >>>  }
> >>> }
> >>>
> >>> Couldn't this theoretically run out of columns for the same search term
> >>> because for each unique term there can (and will) be many timeuuid
> >>> columns?
> >>>
> >>> Thanks for clearing this up for me.
> >>>
> >>>
> >>>
> >
> >
>

Mime
View raw message