cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CASSANDRA-7844) Fetching a single static column requires scanning to the first live CQL row
Date Sat, 13 Sep 2014 00:09:33 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne resolved CASSANDRA-7844.
-----------------------------------------
    Resolution: Not a Problem

As said above, the answer here is to use {{DISTINCT}} so closing this.

> Fetching a single static column requires scanning to the first live CQL row
> ---------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7844
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7844
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Nicolas Favre-Felix
>            Priority: Minor
>              Labels: perfomance
>
> Reading a single static column seems to do more work than needed, scanning the partition
until the first live CQL row before returning a value.
> As I understand, static columns are stored separately from clustered rows (see CASSANDRA-6956
for an issue that arised from this storage model). Nevertheless, Cassandra doesn't optimize
for the case where only static columns and partition key dimensions are retrieved.
> Selecting a static column on its own is possible:
> {code}
> > create table friends (user text, next_id int static, friend_id int, email text,
primary key(user,friend_id));
> > insert into friends (user, next_id) values ('user1', 1);
> > select * from friends where user = 'user1';
>  user  | friend_id | next_id | email
> -------+-----------+---------+-------
>  user1 |      null |       1 |  null
> (1 rows)
> {code}
> Let's insert and delete some clustered data:
> {code}
> > insert into friends (user, next_id, friend_id, email) values ('user1', 2, 1, 'abc@foo');
> > insert into friends (user, next_id, friend_id, email) values ('user1', 3, 2, 'def@foo');
> > insert into friends (user, next_id, friend_id, email) values ('user1', 4, 3, 'ghi@foo');
> > select * from friends where user = 'user1';
>  user  | friend_id | next_id | email
> -------+-----------+---------+---------
>  user1 |         1 |       4 | abc@foo
>  user1 |         2 |       4 | def@foo
>  user1 |         3 |       4 | ghi@foo
> (3 rows)
> > delete from friends where user = 'user1' and friend_id = 1;
> > delete from friends where user = 'user1' and friend_id = 2;
> > delete from friends where user = 'user1' and friend_id = 3;
> {code}
> And then fetch the static column again:
> {code}
> > TRACING ON
> Now tracing requests.
> > select next_id from friends where user = 'user1' limit 1;
>  next_id
> ---------
>        4
> (1 rows)
> Tracing session: 597cc970-2e27-11e4-932f-c551d8e65d14
>  activity                                                                  | timestamp
   | source    | source_elapsed
> ---------------------------------------------------------------------------+--------------+-----------+----------------
>                                                         execute_cql3_query | 13:18:46,792
| 127.0.0.1 |              0
>          Parsing SELECT next_id from friends where user = 'user1' LIMIT 1; | 13:18:46,792
| 127.0.0.1 |             59
>                                                        Preparing statement | 13:18:46,792
| 127.0.0.1 |            125
>                                Executing single-partition query on friends | 13:18:46,792
| 127.0.0.1 |            357
>                                               Acquiring sstable references | 13:18:46,792
| 127.0.0.1 |            369
>                                                Merging memtable tombstones | 13:18:46,792
| 127.0.0.1 |            381
>  Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones | 13:18:46,792
| 127.0.0.1 |            445
>                                 Merging data from memtables and 0 sstables | 13:18:46,792
| 127.0.0.1 |            460
>                                         Read 1 live and 6 tombstoned cells | 13:18:46,792
| 127.0.0.1 |            504
>                                                           Request complete | 13:18:46,792
| 127.0.0.1 |            711
> {code}
>     
>     
> We went over tombstones instead of returning the static column immediately.
> Is this possibly related to CASSANDRA-7085?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message