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....@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....@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.
>>>
>>>
>>>
>
>
