incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milind Parikh <milindpar...@gmail.com>
Subject Re: Manual Conflict Resolution in Cassandra
Date Mon, 25 Apr 2011 10:50:08 GMT
I suppose the term 'silently dropped' is a matter of perspective. C makes an
explicit automated choice of latest-timestamp-wins. In certain situations,
this is not the appropriate choice.

Regards
Milind
/***********************
sent from my android...please pardon occasional typos as I respond @ the
speed of thought
************************/

On Apr 25, 2011 3:54 AM, "David Strauss" <david@davidstrauss.net> wrote:

On Fri, 2011-04-22 at 13:31 -0700, Milind Parikh wrote:
> Is there a chance of getting manual confli...
You can actually already perform "manual conflict resolution" in
Cassandra by naming your columns so that they don't squash each other in
Cassandra's internal replication. Then, ensure the code that accesses
Cassandra reads all columns with data you might need to construct the
resolved value. You could even cache the resolved value if pulling a set
of columns isn't efficient for you.

Optionally, have your code remove columns with obsolete data that's
older than any tolerable window of having a "split brain." This approach
is not elegant, but it would solve the scenario in your PDF.

It seems with Cassandra 0.8's counter support that more pluggable
conflict resolution may not be far off.

>From the PDF:
> Under Quorum, Cassandra guarantees that once a read has seen a write, all
> others will see that same write.

That's not quite true. Under quorum reads and writes, Cassandra
guarantees that a successful read will get data *at least as fresh as*
the last successful write.

Your statement seems to reference something akin to Cassandra's "read
repair" functionality, which is present even at consistency levels lower
than quorum. However, "read repair," gives high likelihood (not a
guarantee) that once a read has happened on a column, subsequent reads
will see the most current write, even if the first read didn't.

>From the PDF:
> It is possible in Cassandra to have updates being silently dropped.

I wouldn't call the updates here "silently dropped" because,  in your
example, Cassandra's conflict resolution is working as-documented. The
update with the later timestamp is, indeed, retained. Cassandra is not
an ACID-compliant system, nor does it strive to be.

David

Mime
View raw message