Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: scode@scode.org
In-Reply-To: <4CC611DE.1010305@gmail.com>
References: <4CBF99A8.7060304@dawningstreams.com>
	<AANLkTik1M1tcUGVY8ufAQUVb-pHUvGzNJWQN=uX=yqHF@mail.gmail.com>
	<4CBFB04E.6090406@gmail.com>
	<AANLkTi=C9SDT0LfvFwDQzCV4eGBjp8p95wObwzKpoWrw@mail.gmail.com>
	<4CC08D51.9080405@gmail.com>
	<AANLkTikRkn9gT+CF9VGNPRG+ia2LQXdAiYAmY7nVpN7D@mail.gmail.com>
	<4CC0CFA2.8020901@gmail.com>
	<AANLkTi=A=HtTWYqs-74JxtTERMvw1D8mKt+dh2WmGiKh@mail.gmail.com>
	<4CC611DE.1010305@gmail.com>
Date: Tue, 26 Oct 2010 21:17:45 +0200
Message-ID: <AANLkTikLo4D-jqMZaCKR4ipR8FN6QPiSV8L5ef2Wmu8G@mail.gmail.com>
Subject: Re: What happens if there is a collision?
From: Peter Schuller <peter.schuller@infidyne.com>
To: =?UTF-8?Q?J=C3=A9r=C3=B4me_Verstrynge?= <jverstry@gmail.com>
Cc: user@cassandra.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> I may have been unclear about the meaning of timestamp in Cassandra. I wa=
s
> under the impression that any given data with the same key value and two
> different timestamps would result in two 'rows'. From what you say, it do=
es
> not seem to be the case. Do you confirm? (In other words, whoever has the
> greatest timestamp destroys the previous records with lower timestamps).

Yes (other than the use of the word "row"). An "insert" of a column (a
column being essentially a key/value pair) causes the key to be
associated with that value. If there was already a column with the
same key, it is replaced. If not, a column is added.

If you have a situation where conflicting writes cannot be allowed,
you'll either have to have some strong co-ordination of writers
outside of Cassandra or else "serialize" the problem by writing
intended changes to some kind of queue/data structure that some
particular guaranteed-to-be-alone Cassandra client processes in batch
mode independently (thereby avoiding the need for co-ordination).

> I know I am boxing a corner case, but I have not seen in the documentatio=
n
> that latest timestamp erases/overwrittes previous data. Now, I may have
> missed something here. May be I did not rub my eyes enough or the coffee =
was
> not operating yet.

I'm not sure where it's most clearly stated and I don't remember how I
figured these things out originally. I think the closest thing on the
wiki would be:

  http://wiki.apache.org/cassandra/DataModel

It does mention that timestamps are used for conflict resolution but
does not really dwell on the issue, and the remainder elides
timestamps. So perhaps it's easy to miss. I also notice that the
phrasing is such that it is not entirely unreasonably to interpret it
like it seems you have.

At the same time that page is somewhat of a mix between internal
models and the model exposed to clients, so I'm not sure how best to
improve the phrasing.

Riptano's recently added documentation may be worth reading:

   http://www.riptano.com/docs/0.6.5/index

Though upon cursory examination I'm not sure whether it is more clear
on this particular point.

> i) That most recent timestamp overwrittes previous entries with lower
> timestamp.

This can definitely be clarified.

> ii) If case of timestamp ties, value breaks ties.

If this is indeed intended to be a guarantee and not an artifact of
the current implementation (anyone want to comment - jbellis?).

> iii) What about ColumnFamilies and SuperColumnFamilies? Do we have the
> guarantee that, in case of timestamp =C2=A0ties, the whole record of the =
winner
> is register (I would assume yes, of course)

Individual columns may be inserted into a SuperColumn so it is not
inserted as one compound value. If writers A and B both do concurrent
insertions to a SuperColumn where A writes column C1 and B writes
column C1 and C2, B's write of C2 will always stick, but C1 will be
subject to individual column conflict resolution. Keep in mind however
that typically timestamps are not allocated/chosen on a per-column
basis by a client. It does occur to me that at this point you may
actually have issues with the timestamp tie and value based conflict
resolution if you are expecting a set of column updates to either
apply or not apply as a group (with respect to some other group of
updates). That's a bit subtle.

Also on the topic of granularity, entire super columns and entire rows
may be deleted without individually referring to all columns. In those
cases, deletes span entire rows or supercolumns rather than individual
columns.

--=20
/ Peter Schuller