cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Malone <m...@simplegeo.com>
Subject Re: Is SuperColumn necessary?
Date Tue, 11 May 2010 15:59:58 GMT
On Tue, May 11, 2010 at 7:46 AM, David Boxenhorn <david@lookin2.com> wrote:

> I would like an API with a variable number of arguments. Using Java
> varargs, something like
>
> value = keyspace.get("articles", "cars", "John Smith", "2010-05-01",
> "comment-25");
>
> or
>
> valueArray = keyspace.get("articles", predicate1, predicate2, predicate3,
> predicate4);
>

Hrm. I haven't dug that deeply into the joys of predicate logic,
propositional DAGs, etc. but couldn't this also be represented as a nested
tree of predicates / other primitives. So it would be something like:

   SubColumns = Transformation that takes a predicate, applies it to a
Column, then gets it's SubColumns
   keyspace.get("articles", SubColumns(predicate1, SubColumns(predicate2,
SubColumns(predicate3, predicate4))));

It's more like functional programming-ish, I suppose, but I think that model
might apply more cleanly here. FP does tend to result in nice clean
algorithms for manipulating large data sets.

Mike


>
>
> The storage layout would be determined by the configuration, as below:
>
> <Column Name="ThingThatsNowKey" Indexed="True" ClusterPartitioned="True"
> ...
>
>
>
>
> On Tue, May 11, 2010 at 5:26 PM, Jonathan Shook <jshook@gmail.com> wrote:
>
>> This is one of the sticking points with the key concatenation
>> argument. You can't simply access subpartitions of data along an
>> aggregate name using a concatenated key unless you can efficiently
>> address a range of the keys according to a property of a subset. I'm
>> hoping this will bear out with more of this discussion.
>>
>> Another facet of this issue is performance with respect to storage
>> layout. Presently columns within a row are inherently organized for
>> efficient range operations. The key space is not generally optimal in
>> this way. I'm hoping to see some discussion of this, as well.
>>
>> On Tue, May 11, 2010 at 6:17 AM, vd <vineetdaniel@gmail.com> wrote:
>> > Hi
>> >
>> > Can we make range search on ID:ID format as this would be treated as
>> > single ID by API or can it bifurcate on ':' . If now then how do can
>> > we ignore usage of supercolumns where we need to associate 'n' number
>> > of rows to a single ID.
>> > Like
>> >          CatID1-> articleID1
>> >          CatID1-> articleID2
>> >          CatID1-> articleID3
>> >          CatID1-> articleID4
>> > How can we map such scenarios with simple column families.
>> >
>> > Rgds.
>> >
>> > On Tue, May 11, 2010 at 2:11 PM, Torsten Curdt <tcurdt@vafer.org>
>> wrote:
>> >> Exactly.
>> >>
>> >> On Tue, May 11, 2010 at 10:20, David Boxenhorn <david@lookin2.com>
>> wrote:
>> >>> Don't think of it as getting rid of supercolum. Think of it as adding
>> >>> superdupercolums, supertriplecolums, etc. Or, in sparse array
>> terminology:
>> >>> array[dim1][dim2][dim3].....[dimN] = value
>> >>>
>> >>> Or, as said above:
>> >>>
>> >>>   <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>
>> >>
>> >
>>
>
>

Mime
View raw message