incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@vafer.org>
Subject Re: Is SuperColumn necessary?
Date Thu, 06 May 2010 07:50:32 GMT
+1 on all of that

On Thu, May 6, 2010 at 09:04, David Boxenhorn <david@lookin2.com> wrote:
> That would be a good time to get rid of the confusing "column" term, which
> incorrectly suggests a two-dimensional tabular structure.
>
> Suggestions:
>
> 1. A hypercube (or hypocube, if only two dimensions): replace "key" and
> "column" with "1st dimension", "2nd dimension", etc.
>
> 2. A file system: replace "key" and "column" with "directory" and
> "subdirectory"
>
> 3. A tuple tree: "Column family" replaced by top-level tuple, whose value is
> the set of keys, whose value is the set of supercolumns of the key, whose
> value is the set of columns for the supercolumn, etc.
>
> 4. Etc.
>
> On Thu, May 6, 2010 at 2:28 AM, Mike Malone <mike@simplegeo.com> wrote:
>>
>> Nice, Ed, we're doing something very similar but less generic.
>> Now replace all of the various methods for querying with a simple query
>> interface that takes a Predicate, allow the user to specify (in
>> storage-conf) which levels of the nested Columns should be indexed, and
>> completely remove Comparators and have people subclass Column / implement
>> IColumn and we'd really be on to something ;).
>> Mock storage-conf.xml:
>>   <Column Name="ThingThatsNowKey" Indexed="True" ClusterPartitioned="True"
>> Type="UTF8">
>>     <Column Name="ThingThatsNowColumnFamily" DiskPartitioned="True"
>> Type="UTF8">
>>       <Column Name="ThingThatsNowSuperColumnName" Type="Long">
>>         <Column Name="ThingThatsNowColumnName" Indexed="True"
>> Type="ASCII">
>>           <Column Name="ThingThatCantCurrentlyBeRepresented"/>
>>         </Column>
>>       </Column>
>>     </Column>
>>   </Column>
>> Thrift:
>>   struct NamePredicate {
>>     1: required list<binary> column_names,
>>   }
>>   struct SlicePredicate {
>>     1: required binary start,
>>     2: required binary end,
>>   }
>>   struct CountPredicate {
>>     1: required struct predicate,
>>     2: required i32 count=100,
>>   }
>>   struct AndPredicate {
>>     1: required Predicate left,
>>     2: required Predicate right,
>>   }
>>   struct SubColumnsPredicate {
>>     1: required Predicate columns,
>>     2: required Predicate subcolumns,
>>   }
>>   ... OrPredicate, OtherUsefulPredicates ...
>>   query(predicate, count, consistency_level) # Count here would be total
>> count of leaf values returned, whereas CountPredicate specifies a column
>> count for a particular sub-slice.
>> Not fully baked... but I think this could really simplify stuff and make
>> it more flexible. Downside is it may give people enough rope to hang
>> themselves, but at least the predicate stuff is easily distributable.
>> I'm thinking I'll play around with implementing some of this stuff myself
>> if I have any free time in the near future.
>> Mike
>>
>> On Wed, May 5, 2010 at 2:04 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
>>>
>>> Very interesting, thanks!
>>>
>>> On Wed, May 5, 2010 at 1:31 PM, Ed Anuff <ed@anuff.com> wrote:
>>> > Follow-up from last weeks discussion, I've been playing around with a
>>> > simple
>>> > column comparator for composite column names that I put up on github.
>>> > I'd
>>> > be interested to hear what people think of this approach.
>>> >
>>> > http://github.com/edanuff/CassandraCompositeType
>>> >
>>> > Ed
>>> >
>>> > On Wed, Apr 28, 2010 at 12:52 PM, Ed Anuff <ed@anuff.com> wrote:
>>> >>
>>> >> It might make sense to create a CompositeType subclass of AbstractType
>>> >> for
>>> >> the purpose of constructing and comparing these types of "composite"
>>> >> column
>>> >> names so that if you could more easily do that sort of thing rather
>>> >> than
>>> >> having to concatenate into one big string.
>>> >>
>>> >> On Wed, Apr 28, 2010 at 10:25 AM, Mike Malone <mike@simplegeo.com>
>>> >> wrote:
>>> >>>
>>> >>> The only thing SuperColumns appear to buy you (as someone pointed
out
>>> >>> to
>>> >>> me at the Cassandra meetup - I think it was Eric Florenzano) is
that
>>> >>> you can
>>> >>> use different comparator types for the Super/SubColumns, I guess..?
>>> >>> But you
>>> >>> should be able to do the same thing by creating your own Column
>>> >>> comparator.
>>> >>> I guess my point is that SuperColumns are mostly a convenience
>>> >>> mechanism, as
>>> >>> far as I can tell.
>>> >>> Mike
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Jonathan Ellis
>>> Project Chair, Apache Cassandra
>>> co-founder of Riptano, the source for professional Cassandra support
>>> http://riptano.com
>>
>
>

Mime
View raw message