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

Reply via email to