Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
Sender: scode@scode.org
In-Reply-To: <4E0434FF.2080702@dude.podzone.net>
References: <4E0434FF.2080702@dude.podzone.net>
Date: Fri, 24 Jun 2011 09:11:20 +0200
Message-ID: <BANLkTi=rnmAuMCXGfb0LB=2QM4hYDibOnQ@mail.gmail.com>
Subject: Re: Cassandra ACID
From: Peter Schuller <peter.schuller@infidyne.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> Atomicity
> All individual writes are atomic at the row level.=C2=A0 So, a batch muta=
te for
> one specific key will apply updates to all the columns for that one speci=
fic
> row atomically.=C2=A0 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'.=C2=A0 Note: atomicity and is=
olation
> 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 user=
s'
> updates or reads.
> Refs: http://wiki.apache.org/cassandra/FAQ#batch_mutate_atomic

Atomicity is sort of provided, but there's no reversion going on.
Cassandra does validation of batch mutations prior to their
application and then tries to apply it. In the absence of bugs in
Cassandra, it should generally be safe to say that writes are then
guaranteed to succeed. However I wouldn't necessarily rely on this
type of atomicity to the same level that I would in e.g. PostgreSQL.

One example of violated atomicity is when you run with periodic commit
log mode instead of batch wise. If you for example perform a write on
CL.ONE but the node that took the write got killed (eg SIGKILL) before
the periodic commit log flush, you will have eaten a write that then
gets dropped. If someone read the changes that the write entails, the
application-visible behavior will be that the write will be "undone"
rather than eventually done.

> 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

For the limited definition of consistency it provides, yes. One thing
to be aware of is that *failed* writes at QUORUM followed by
*succeeding* reads at QUORUM may have readers see inconsistent results
across requests (see
https://issues.apache.org/jira/browse/CASSANDRA-2494 although I still
think it's a designed-for behavior rather than a bug). And of course
the usual bits about concurrent updates and updates spanning multiple
rows.

I'm just a bit hesitant to agree to the term "100% consistency" since
it sounds very all-encompassing :)

> Isolation
> NOTHING is isolated; because there is no transaction support in the first
> place.=C2=A0 This means that two or more clients can update the same row =
at the
> same time.=C2=A0 Their updates of the same or different columns may be
> interleaved and leave the row in a state that may not make sense dependin=
g
> on your application.=C2=A0 Note: this doesn't mean to say that two update=
s 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.

Yes but the relevant lack of isolation is for reads. Due to
Cassandra's conflict resolution model, given two updates with certain
timestamps associated with them, the actual timing of the writes will
not change the eventual result in the data (absent read-before-write
logic operating on that data concurrently).

The lack of isolation is thus mostly of concern to readers.

> Durability
> Updates are made durable by the use of the commit log.=C2=A0 No worries h=
ere.

But be careful about choosing batch commit log sync instead of
periodic if single-node durability or post-quorum-write durability is
a concern.

--=20
/ Peter Schuller