cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Anastasyev <>
Subject Re: Manual Conflict Resolution in Cassandra
Date Wed, 27 Apr 2011 08:00:51 GMT
David Strauss <david <at>> writes:

> 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.

In my case this approach rised cost of the system 2x, because amount of data
need to be stored increased (columns were not compacted because now they have
different names -> more storage, more servers) and led to another month of
I believe for apps with many updates to the same column this solution just 
dont fit.

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

This will only solve incrementing counters. Cassandra really needs vector 
clocks with pluggable app level conflict resolution support on compaction 
and read stages.

> 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.

Even if design flaw is documented, it is still a design flaw. In practice,
single timestamp based conflict resolution hides conflicts from developer, not
resolves them. And it forces developer to implement home grown conflict
detection and resolution schemas, which are very difficult to debug, instead of
having them solved in generic way once.

Currently, for systems with high update rate to single column my advice would
be: just dont use cassandra.

View raw message