cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8273) Allow filtering queries can return stale data
Date Mon, 02 May 2016 11:21:12 GMT

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

Robert Stupp commented on CASSANDRA-8273:
-----------------------------------------

{{ALLOW FILTERING}} cannot provide _any_ consistency guarantee, since even {{ONE}} could end
up on a replica with stale data - but that's the expected behavior for CL {{ONE}}.

I think the point that may confuse people, is that {{ALLOW FILTERING}} + {{QUORUM}} doesn't
really respect the CL.

Maybe it's worth to add a warning, if CL > {{ONE}} is used with {{ALLOW FILTERING}}. WDYT?

With CL {{ONE}} + {{ALLOW FILTERING}} _and_ partition (or token) restriction, it shouldn't
make a (big) difference where the filtering takes place. But for filtering queries w/ 2i (or
no partition/token restriction) it could make a huge difference.

Maybe we can use replica filtering for CL {{ONE}} and coordinator filtering otherwise. OTOH,
as you said, it makes the code path more complex.

(PS: Strike my last comment.)

> Allow filtering queries can return stale data
> ---------------------------------------------
>
>                 Key: CASSANDRA-8273
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8273
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>
> Data filtering is done replica side. That means that a single replica with stale data
may make the whole query return that stale data.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v1 text, v2 int);
> CREATE INDEX ON test(v1);
> INSERT INTO test(k, v1, v2) VALUES (0, 'foo', 1);
> {noformat}
> with every replica up to date. Now, suppose that the following queries are done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v2 = 2 WHERE k = 0;
> SELECT * FROM test WHERE v1 = 'foo' AND v2 = 1;
> {noformat}
> then, if A and B acknowledge the insert but C respond to the read before having applied
the insert, then the now stale result will be returned. Let's note that this is a problem
related to filtering, not 2ndary indexes.
> This issue share similarity with CASSANDRA-8272 but contrarily to that former issue,
I'm not sure how to fix it. Obviously, moving the filtering to the coordinator would remove
that problem, but doing so would, on top of not being trivial to implmenent, have serious
performance impact since we can't know in advance how much data will be filtered and we may
have to redo query to replica multiple times.



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

Mime
View raw message