Please create a new term word if the existing terms are misleading, if its
not a file system then its not good to call it a file system.
On Thu, May 6, 2010 at 3:50 PM, Torsten Curdt tcu...@vafer.org wrote:
+1 on all of that
On Thu, May 6, 2010 at 09:04, 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 listbinary 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
