cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Newsham <jnews...@referentia.com>
Subject Re: Cassandra ACID
Date Fri, 24 Jun 2011 19:46:28 GMT
On 6/23/2011 8:55 PM, AJ wrote:
> Can any Cassandra contributors/guru's confirm my understanding of 
> Cassandra's degree of support for the ACID properties?
>
> I provide official references when known.  Please let me know if I 
> missed some good official documentation.
>
> *Atomicity*
> All individual writes are atomic at the row level.  So, a batch mutate 
> for one specific key will apply updates to all the columns for that 
> one specific row atomically.  If part of the single-key batch update 
> fails, then all of the updates will be reverted since they all 
> pertained to one key/row.  Notice, I said 'reverted' not 'rolled 
> back'.  Note: atomicity and isolation are related to the topic of 
> transactions but one does not imply the other.  Even though row 
> updates are atomic, they are not isolated from other users' updates or 
> reads.
> Refs: http://wiki.apache.org/cassandra/FAQ#batch_mutate_atomic
>
> *Consistency*
> If you want 100% consistency, use consistency level QUORUM for both 
> reads and writes and EACH_QUORUM in a multi-dc scenario.
> Refs: http://wiki.apache.org/cassandra/ArchitectureOverview
>

This is a pretty narrow interpretation of consistency.  In a traditional 
database, consistency prevents you from getting into a logically 
inconsistent state, where records in one table do not agree with records 
in another table.  This includes referential integrity, cascading 
deletes, etc.  It seems to me Cassandra has no support for this concept 
whatsoever.

> *Isolation*
> NOTHING is isolated; because there is no transaction support in the 
> first place.  This means that two or more clients can update the same 
> row at the same time.  Their updates of the same or different columns 
> may be interleaved and leave the row in a state that may not make 
> sense depending on your application.  Note: this doesn't mean to say 
> that two updates of the same column will be corrupted, obviously; 
> columns are the smallest atomic unit ('atomic' in the more general 
> thread-safe context).
> Refs: None that directly address this explicitly and clearly and in 
> one place.
>
> *Durability*
> Updates are made durable by the use of the commit log.  No worries here.
> Refs: Plenty.

Jim

Mime
View raw message