On Fri, 2011-04-22 at 13:31 -0700, Milind Parikh wrote: > Is there a chance of getting manual conflict resolution in Cassandra? > Please see attachment for why this is important in some cases.
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
signature.asc
Description: This is a digitally signed message part
