Maybe... but honestly, it doesn't affect the architecture or interface at
all. I'm more interested in thinking about how the system should work than
what things are called. Naming things are important, but that can happen
later.
Does anyone have any thoughts or comments on the architecture I suggested
earlier?
Mike
On Mon, May 10, 2010 at 8:36 AM, Schubert Zhang <zson...@gmail.com> wrote:
> Yes, the "column" here is not appropriate.
> Maybe we need not to create new terms, in Google's Bigtable, the term
> "qualifier" is a good one.
>
>
> On Thu, May 6, 2010 at 3:04 PM, David Boxenhorn <da...@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 <m...@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 <jbel...@gmail.com>wrote:
>>>
>>>> Very interesting, thanks!
>>>>
>>>> On Wed, May 5, 2010 at 1:31 PM, Ed Anuff <e...@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 <e...@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 <m...@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
>>>>
>>>
>>>
>>
>
