You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Greg Fausak <gr...@named.com> on 2012/08/01 02:18:36 UTC

Re: Dynamic CF

I thought I'd give this a try:

create columnfamily
    at_event__ac_c
(
    ac_c text,
    ac_creation bigint,
    ac_name text,
    ac_value text,
    PRIMARY KEY (ac_c, ac_creation)
) with compression_parameters:sstable_compression = '';

Then, insert a few columns:

begin batch using consistency quorum
insert into at_event__ac_c (ac_c, ac_creation, ac_name, ac_value)
values ('83433.361.t4.l1.cisco.com', 1303167920747402,
'ac_event_type', 'SERV.CPE.CONN')
insert into at_event__ac_c (ac_c, ac_creation, ac_name, ac_value)
values ('83433.361.t4.l1.cisco.com', 1303167920747402, 'ac_vid', '')
insert into at_event__ac_c (ac_c, ac_creation, ac_name, ac_value)
values ('83433.361.t4.l1.cisco.com', 1303167920747402, 'ac_state',
'UP')
apply batch;

then followed up with a query:
cqlsh:op2> select * from at_event__ac_c;
 ac_c                      | ac_creation      | ac_name  | ac_value
---------------------------+------------------+----------+----------
 83433.361.t4.l1.cisco.com | 1303167920747402 | ac_state |       UP

So, I can't get the same index behavior from the ac_creation column
as I get from the ac_c column.  That is, ac_c is additive, ac_creation
overwrites.  When I turn this around and create a real wide row, like this:

create columnfamily
    at_event__ac_c
(
    ac_c text,
    ac_creation bigint,
    ac_event_type text,
    ac_vid text,
    ac_state text,
    PRIMARY KEY (ac_c, ac_creation)
) with compression_parameters:sstable_compression = '';

I get the behavior I want, which is a composite row which is indexed
by ac_c and ac_creation.

If I have 100 columns defined as a static CF (like above), when I do an insert
does it just use the space for the columns inserted, or the columns declared?

-g


On Tue, Jul 10, 2012 at 7:23 AM, Sylvain Lebresne <sy...@datastax.com> wrote:
> On Fri, Jul 6, 2012 at 10:49 PM, Leonid Ilyevsky
> <li...@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