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 <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
