David Strauss <david <at> davidstrauss.net> 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 development. 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.
