You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by al...@ceid.upatras.gr on 2011/09/09 17:41:07 UTC
Mutations during selects
I see that Cassandra updates secondary indices as soon as a value of the
indexed column is updated. This can happen, for example, during a select
query with a condition on a secondary index. Does Cassandra perform no
checking or locking? Will the result of this select, with old and new
values, be returned as is? Am I missing some reason why this isn't a
problem?
Alexander
Re: Mutations during selects
Posted by Jonathan Ellis <jb...@gmail.com>.
Cassandra makes no attempt to provide cross-row isolation or atomicity.
(Within a row, it technically provides atomicity but not isolation.)
On Fri, Sep 9, 2011 at 9:33 PM, <al...@ceid.upatras.gr> wrote:
> I a thinking about a scenario that goes like this: a node is reading a
> secondary index to reply to a select query. While in the middle of this,
> two rows are mutated, one that has already been read and considered for
> the select result, and one that is yet to be processed. Say both rows
> where changed in a way that causes them to be included to the result. The
> result however will contain only the second one, and will not represent
> the correct select result, neither before or after said mutation.
>
> This is extreme, I know, but given a cluster with enough activity, I don't
> believe it's impossible. So I guess the answer is, Cassandra doesn't care,
> the result is not guaranteed to represent a valid snapshot of the
> database, but is very likely to?
>
> Alexander
>
>> Consider this scenario in a SQL database:
>>
>> UPDATE foo SET x = 1 WHERE key = 'asdf';
>>
>> Now, "simultaneously," two clients run
>>
>> UPDATE foo SET x = 2 WHERE key = 'asdf';
>> and
>> SELECT * FROM foo WHERE x = 1;
>>
>> Either you get back row asdf, or you don't. Either is valid. Same
>> thing happens with Cassandra indexes.
>>
>> On Fri, Sep 9, 2011 at 10:41 AM, <al...@ceid.upatras.gr> wrote:
>>> I see that Cassandra updates secondary indices as soon as a value of the
>>> indexed column is updated. This can happen, for example, during a select
>>> query with a condition on a secondary index. Does Cassandra perform no
>>> checking or locking? Will the result of this select, with old and new
>>> values, be returned as is? Am I missing some reason why this isn't a
>>> problem?
>>>
>>> Alexander
>>>
>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder of DataStax, the source for professional Cassandra support
>> http://www.datastax.com
>>
>>
>
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: Mutations during selects
Posted by al...@ceid.upatras.gr.
I a thinking about a scenario that goes like this: a node is reading a
secondary index to reply to a select query. While in the middle of this,
two rows are mutated, one that has already been read and considered for
the select result, and one that is yet to be processed. Say both rows
where changed in a way that causes them to be included to the result. The
result however will contain only the second one, and will not represent
the correct select result, neither before or after said mutation.
This is extreme, I know, but given a cluster with enough activity, I don't
believe it's impossible. So I guess the answer is, Cassandra doesn't care,
the result is not guaranteed to represent a valid snapshot of the
database, but is very likely to?
Alexander
> Consider this scenario in a SQL database:
>
> UPDATE foo SET x = 1 WHERE key = 'asdf';
>
> Now, "simultaneously," two clients run
>
> UPDATE foo SET x = 2 WHERE key = 'asdf';
> and
> SELECT * FROM foo WHERE x = 1;
>
> Either you get back row asdf, or you don't. Either is valid. Same
> thing happens with Cassandra indexes.
>
> On Fri, Sep 9, 2011 at 10:41 AM, <al...@ceid.upatras.gr> wrote:
>> I see that Cassandra updates secondary indices as soon as a value of the
>> indexed column is updated. This can happen, for example, during a select
>> query with a condition on a secondary index. Does Cassandra perform no
>> checking or locking? Will the result of this select, with old and new
>> values, be returned as is? Am I missing some reason why this isn't a
>> problem?
>>
>> Alexander
>>
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
>
>
Re: Mutations during selects
Posted by Jonathan Ellis <jb...@gmail.com>.
Consider this scenario in a SQL database:
UPDATE foo SET x = 1 WHERE key = 'asdf';
Now, "simultaneously," two clients run
UPDATE foo SET x = 2 WHERE key = 'asdf';
and
SELECT * FROM foo WHERE x = 1;
Either you get back row asdf, or you don't. Either is valid. Same
thing happens with Cassandra indexes.
On Fri, Sep 9, 2011 at 10:41 AM, <al...@ceid.upatras.gr> wrote:
> I see that Cassandra updates secondary indices as soon as a value of the
> indexed column is updated. This can happen, for example, during a select
> query with a condition on a secondary index. Does Cassandra perform no
> checking or locking? Will the result of this select, with old and new
> values, be returned as is? Am I missing some reason why this isn't a
> problem?
>
> Alexander
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com