cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Lerer (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-8940) Inconsistent select count and select distinct
Date Fri, 08 May 2015 20:41:00 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535458#comment-14535458
] 

Benjamin Lerer edited comment on CASSANDRA-8940 at 5/8/15 8:40 PM:
-------------------------------------------------------------------

[~frensjan], you did not succeed to reproduce the problem with ccm because by default ccm
disable {{vnodes}}. This means that the data will be distributed on only 3 contiguous ranges
and the {{StoreProxy}} will have to perform at most 2 requests.

If the ccm cluster is created with the {{vnodes}} option. The data will be distributed over
256 * 3 = 768 ranges and the problem is easily reproducible.

In our scenario, for each page of data (5000 cql rows), the {{StoreProxy}} will initially
send a first request and check if enough results are returned. If not enough result have been
returned it will guess based on the amount of data returned for the first range how much more
range it needs to query and will query them in parallel.

In the worst case, where no result have been found in the first range, the {{StoreProxy}}
will assume that we only have a small amount of data per range and will issue 767 concurrent
requests to get the remaining data.     
A third of those request will target some ranges of data located on the coordinator node.


Cassandra will optimise those requests by not serializing and deserializing them.

The problem was that the {{SliceQueryFilter}} which is part of the request and which is used
to filter out the data ended up being shared between the threads while it should not have
been as it is mutable.  

I described worst case scenario but the problem could occurs with a smaller amount of concurrent
requests.



was (Author: blerer):
[~frensjan], you did not succeed to reproduce the problem with ccm because by default ccm
disable {{vnodes}}. This means that the data will be distributed on only 3 contiguous ranges
and the {{StoreProxy}} will have to perform at most 2 requests.

If the ccm cluster is created with the {{vnodes}} option. The data will be distributed over
256 * 3 = 768 ranges and the problem is easily reproducible.

In our scenario, for each page of data (5000 cql rows), the {{StoreProxy}} will initially
issue a first request and check if enough results are returned. If not enough result have
been returned it will guess based on the amount of data returned for the first range how much
more range it needs to query and will query them in parallel.

In the worst case, where no result have been found in the first range, the {{StoreProxy}}
will assume that we only have a small amount of data per range and will issue 767 concurrent
requests to get the remaining data.     
A third of those request will target some ranges of data located on the coordinator node.


Cassandra will optimise those requests by not serializing and deserializing them.

The problem was that the {{SliceQueryFilter}} which is part of the request and which is used
to filter out the data ended up being shared between the threads while it should not have
been as it is mutable.  

I described worst case scenario but the problem could occurs with a smaller amount of concurrent
requests.


> Inconsistent select count and select distinct
> ---------------------------------------------
>
>                 Key: CASSANDRA-8940
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8940
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: 2.1.2
>            Reporter: Frens Jan Rumph
>            Assignee: Benjamin Lerer
>         Attachments: 7b74fb00-e935-11e4-b10c-317579db7eb4.csv, 8d5899d0-e935-11e4-847b-2d06da75a6cd.csv,
Vagrantfile, install_cassandra.sh, setup_hosts.sh
>
>
> When performing {{select count( * ) from ...}} I expect the results to be consistent
over multiple query executions if the table at hand is not written to / deleted from in the
mean time. However, in my set-up it is not. The counts returned vary considerable (several
percent). The same holds for {{select distinct partition-key-columns from ...}}.
> I have a table in a keyspace with replication_factor = 1 which is something like:
> {code}
> CREATE TABLE tbl (
>     id frozen<id_type>,
>     bucket bigint,
>     offset int,
>     value double,
>     PRIMARY KEY ((id, bucket), offset)
> )
> {code}
> The frozen udt is:
> {code}
> CREATE TYPE id_type (
>     tags map<text, text>
> );
> {code}
> The table contains around 35k rows (I'm not trying to be funny here ...). The consistency
level for the queries was ONE.



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

Mime
View raw message