I think he means something like having a fixed set of coiumns in the table
definition, then in the actual rows having other columns not specified in
the defintion, indepentent of the composited part of the PK. When I
reviewed CQL3 for using in Gossie[1] I realized I couldn't have this, and
that it would complicate things like migrations or optional columns. For
this reason I didn't use CQL3 and instead wrote a row unmaper that detects
the discontinuities in the composited part and uses those as the boundaries
for the individual concrete rows stored in a wide row [2]. For example:
Given a Timeline table defined as key validation UTF8Type, column name
validation CompositeType(LongType, AsciiType), value validation BytesType:
Timeline: {
user1: {
1341933021000000: {
Author: "Tom",
Body: "Hey!"
},
1341933022000000: {
Author: "Paul",
Body: "Nice",
Lat: 40.0,
Lon: 20.0
},
1341933023000000: {
Author: "Lana",
Body: "Cool"
}
},
...
}
Both of the following structs are valid and will be able to be unmaped from
the wide row "user1":
type Tweet struct {
UserID string `cf:"Timeline" key:"UserID" cols:"When"`
When int64
Author string
Body string
}
type GeoTweet struct {
UserID string `cf:"Timeline" key:"UserID" cols:"When"`
When int64
Author string
Body string
Lat float32
Lon float32
}
Granted I lose database-side validation over the individual column values
(BytesType) but in exchange I get very flexible rows and much nicer
behaviour for model changes and migrations.
1: https://github.com/carloscm/gossie
2: https://github.com/carloscm/gossie/blob/master/src/gossie/mapping.go#L339
On 10 July 2012 14:23, Sylvain Lebresne <sylv...@datastax.com> wrote:
> On Fri, Jul 6, 2012 at 10:49 PM, Leonid Ilyevsky
> <lilyev...@mooncapital.com> wrote:
> > At this point I am really confused about what direction Cassandra is
> going. CQL 3 has the benefit of composite keys, but no dynamic columns.
> > I thought, the whole point of Cassandra was to provide dynamic tables.
>
> CQL3 absolutely provide "dynamic tables"/wide rows, the syntax is just
> different. The typical example for wide rows is a time serie, for
> instance keeping all the events for a given event_kind in the same C*
> row ordered by time. You declare that in CQL3 using:
> CREATE TABLE events (
> event_kind text,
> time timestamp,
> event_name text,
> event_details text,
> PRIMARY KEY (event_kind, time)
> )
>
> The important part in such definition is that one CQL row (i.e a given
> event_kind, time, event_name, even_details) does not map to an internal
> Cassandra row. More precisely, all events sharing the same event_kind will
> be
> in the same internal row. This is a wide row/dynamic table in the sense of
> thrift.
>
>
> > I need to have a huge table to store market quotes, and be able to query
> it by name and timestamp (t1 <= t <= t2), therefore I wanted the composite
> key.
> > Loading data to such table using prepared statements (CQL 3-based) was
> very slow, because it makes a server call for each row.
>
> You should use a BATCH statement which is the equivalent to batch_mutate.
>
> --
> Sylvain
>
--
<http://www.groupalia.com/>Carlos CarrascoIT - Software Architect
Llull, 95-97, 2ยบ planta, 08005 BarcelonaSkype: carlos.carrasco.groupalia
www.groupalia.comcarlos.carra...@groupalia.com
