Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 10 Dec 2014 14:06:13 +0000 (UTC)
From: "Philo Yang (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12756981.1416578985000.119775.1418220373263@Atlassian.JIRA>
In-Reply-To: <JIRA.12756981.1416578985000@Atlassian.JIRA>
References: <JIRA.12756981.1416578985000@Atlassian.JIRA>
 <JIRA.12756981.1416578985616@arcas>
Subject: [jira] [Commented] (CASSANDRA-8356) Slice query on a super column
 family with counters doesn't get all the data
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-8356?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14241116#comment-14241116 ]=20

Philo Yang commented on CASSANDRA-8356:
---------------------------------------

Hi, in fact I have the same trouble for missing data on slice query. My clu=
ster is 2.1.1, and regular table(create by cql3, no counter). My table is l=
ike this:

{noformat}
CREATE TABLE word (
    user text,
    word text,
    alter_time bigint,
    (some other column...)
    PRIMARY KEY (user, word)
) WITH CLUSTERING ORDER BY (word ASC)
{noformat}

If a row with 26 column whose column names are "a","b"..."z".

Usually I query this table like this:
{noformat}
select * from word where user =3D 'userid';
{noformat}
and it should return 26 rows in cql.

However, in some rows (most of rows in this table won't lose data) it retur=
n only part of columns, some row(row for cql, column for cassandra ), will =
not return even in consistency level ALL. The row that doesn't return is fi=
xed for querying many times. For example, "b", is a row that is missing. If=
 I query like
{noformat}
select * from word where user =3D 'userid';
or
select * from word where user =3D 'userid' and word >'a';
or
select * from word where user =3D 'userid' and word <=3D'b';
or
select * from word where user =3D 'userid' and word <=3D'b' order by word d=
esc;
or
select * from word where user =3D 'userid' and word <'z';
{noformat}
'b' is always missing.

But if I query like:
{noformat}
select * from word where user =3D 'userid' and word =3D'b';
or
select * from word where user =3D 'userid' and word >=3D'b';
or
select * from word where user =3D 'userid' and word >=3D'b' order by word d=
esc;
{noformat}

It will show in result set.


=20

> Slice query on a super column family with counters doesn't get all the da=
ta
> -------------------------------------------------------------------------=
--
>
>                 Key: CASSANDRA-8356
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8356
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Nicolas Lalev=C3=A9e
>            Assignee: Aleksey Yeschenko
>             Fix For: 2.0.12
>
>
> We've finally been able to upgrade our cluster to 2.0.11, after CASSANDRA=
-7188 being fixed.
> But now slice queries on a super column family with counters doesn't retu=
rn all the expected data. We first though because of all the trouble we had=
 that we lost data, but there a way to actually get the data, so nothing is=
 lost; it just that cassandra seems to incorrectly skip it.
> See the following CQL log:
> {noformat}
> cqlsh:Theme> desc table theme_view;
> CREATE TABLE theme_view (
>   key bigint,
>   column1 varint,
>   column2 text,
>   value counter,
>   PRIMARY KEY ((key), column1, column2)
> ) WITH COMPACT STORAGE AND
>   bloom_filter_fp_chance=3D0.010000 AND
>   caching=3D'KEYS_ONLY' AND
>   comment=3D'' AND
>   dclocal_read_repair_chance=3D0.000000 AND
>   gc_grace_seconds=3D864000 AND
>   index_interval=3D128 AND
>   read_repair_chance=3D1.000000 AND
>   replicate_on_write=3D'true' AND
>   populate_io_cache_on_flush=3D'false' AND
>   default_time_to_live=3D0 AND
>   speculative_retry=3D'99.0PERCENTILE' AND
>   memtable_flush_period_in_ms=3D0 AND
>   compaction=3D{'class': 'SizeTieredCompactionStrategy'} AND
>   compression=3D{'sstable_compression': 'SnappyCompressor'};
> cqlsh:Theme> select * from theme_view where key =3D 99421 limit 10;
>  key   | column1 | column2    | value
> -------+---------+------------+-------
>  99421 |     -12 | 2011-03-25 |    59
>  99421 |     -12 | 2011-03-26 |     5
>  99421 |     -12 | 2011-03-27 |     2
>  99421 |     -12 | 2011-03-28 |    40
>  99421 |     -12 | 2011-03-29 |    14
>  99421 |     -12 | 2011-03-30 |    17
>  99421 |     -12 | 2011-03-31 |     5
>  99421 |     -12 | 2011-04-01 |    37
>  99421 |     -12 | 2011-04-02 |     7
>  99421 |     -12 | 2011-04-03 |     4
> (10 rows)
> cqlsh:Theme> select * from theme_view where key =3D 99421 and column1 =3D=
 -12 limit 10;
>  key   | column1 | column2    | value
> -------+---------+------------+-------
>  99421 |     -12 | 2011-03-25 |    59
>  99421 |     -12 | 2014-05-06 |    15
>  99421 |     -12 | 2014-06-06 |     7
>  99421 |     -12 | 2014-06-10 |    22
>  99421 |     -12 | 2014-06-11 |    34
>  99421 |     -12 | 2014-06-12 |    35
>  99421 |     -12 | 2014-06-13 |    26
>  99421 |     -12 | 2014-06-14 |    16
>  99421 |     -12 | 2014-06-15 |    24
>  99421 |     -12 | 2014-06-16 |    25
> (10 rows)
> {noformat}
> As you can see the second query should return data from 2012, but it is n=
ot. Via thrift, we have the exact same bug.


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