cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jeske <dav...@gmail.com>
Subject Re: cassandra vs hbase summary (was facebook messaging)
Date Mon, 22 Nov 2010 21:58:05 GMT
On Mon, Nov 22, 2010 at 11:52 AM, Todd Lipcon <todd@lipcon.org> wrote:

> Not quite. The replica synchronization code is pretty messy, but basically
> it will take the longest replica that may have been synced, not a quorum.
>
> i.e the guarantee is that "if you successfully sync() data, it will be
> present after replica synchronization". Unsynced data *may* be present after
> replica synchronization.
>
> But keep in mind that recovery is blocking in most cases - ie if the RS is
> writing to a pipeline and waiting on acks, and one of the nodes in the
> pipeline dies, then it will recover the pipeline (without the dead node) and
> continue syncing to the remaining two nodes. The client is still blocked at
> this point.
>

I see. So it sounds like my statement #1 was wrong. Will the RS ever timeout
the write and fail in the face of not being able to push it to HDFS?

Is it correct to say:

Once a write is issued to HBase, it will either catistrophicly fail (i.e.
disconnect), in which case the write with either have failed or succeeded,
and if it succeeded, future reads will always show that write? As opposed to
Cassandra, which in all configurations where reads allow a subset of all
nodes, can "fail" a write while having the write show a temporary period of
inconsistency (depending on who you talk to) followed by the write either
applying or not applying depending on whether or not it actually wrote a
single node during the "failure to meet the write consistency request"?

Does Cassandra have any return result which distinguishes between these two
states:

1 - your data was not written to any nodes (true failure)
2 - your data was written to at least 1 node, but not enough to meet your
write-consistency count

?

Mime
View raw message