Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of jbellis@gmail.com designates
 74.125.82.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAnh3_-P3dcnf3NjEW7przb_XLeTTVzxUFKFnP8UpcL5obhA_w@mail.gmail.com>
References: <4E0E7A07.2050807@dude.podzone.net>
 <CAAnh3_-P3dcnf3NjEW7przb_XLeTTVzxUFKFnP8UpcL5obhA_w@mail.gmail.com>
From: Jonathan Ellis <jbellis@gmail.com>
Date: Sat, 2 Jul 2011 12:11:43 -0500
Message-ID: 
 <CALdd-zjqSO3tvnvR1OednDkVdmdYGPcV0VV7z-bRSHigApPGJg@mail.gmail.com>
Subject: Re: Strong Consistency with ONE read/writes
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The way HBase uses ZK (for master election) is not even close to how
Cassandra uses the failure detector.

Using ZK for each operation would (a) not scale and (b) not work
cross-DC for any reasonable latency requirements.

On Sat, Jul 2, 2011 at 11:55 AM, Yang <teddyyyy123@gmail.com> wrote:
> there is a JIRA completed in 0.7.x that "Prefers" a certain node in snitc=
h,
> so this does roughly what you want MOST of the time
>
> but the problem is that it does not GUARANTEE that the same node will alw=
ays
> be read. =A0I recently read into the HBase vs Cassandra comparison thread=
 that
> started after Facebook dropped Cassandra for their messaging system, and
> understood some of the differences. what you want is essentially what HBa=
se
> does. the fundamental difference there is really due to the gossip protoc=
ol:
> it's a probablistic, or eventually consistent failure detector =A0while
> HBase/Google Bigtable use Zookeeper/Chubby to provide a strong failure
> detector (a distributed lock). =A0so in HBase, if a tablet server goes do=
wn,
> it really goes down, it can not re-grab the tablet from the new tablet
> server without going through a start up protocol (notifying the master,
> which would notify the clients etc), =A0in other words it is guaranteed t=
hat
> one tablet is served by only one tablet server at any given time. =A0in
> comparison the above JIRA only TRYIES to serve that key from one particul=
ar
> replica. HBase can have that guarantee because the group membership is
> maintained by the strong failure detector.
> just for hacking curiosity, a strong failure detector + Cassandra replica=
s
> is not impossible (actually seems not difficult), although the performanc=
e
> is not clear. what would such a strong failure detector bring to Cassandr=
a
> besides this ONE-ONE strong consistency ? that is an interesting question=
 I
> think.
> considering that HBase has been deployed on big clusters, it is probably =
OK
> with the performance of the strong =A0Zookeeper failure detector. then a
> further question was: why did Dynamo originally choose to use the
> probablistic failure detector? yes Dynamo's main theme is "eventually
> consistent", so the Phi-detector is **enough**, but if a strong detector
> buys us more with little cost, wouldn't that =A0be great?
>
>
> On Fri, Jul 1, 2011 at 6:53 PM, AJ <aj@dude.podzone.net> wrote:
>>
>> Is this possible?
>>
>> All reads and writes for a given key will always go to the same node fro=
m
>> a client. =A0It seems the only thing needed is to allow the clients to c=
ompute
>> which node is the closes replica for the given key using the same algori=
thm
>> C* uses. =A0When the first replica receives the write request, it will w=
rite
>> to itself which should complete before any of the other replicas and the=
n
>> return. =A0The loads should still stay balanced if using random partitio=
ner.
>> =A0If the first replica becomes unavailable (however that is defined), t=
hen
>> the clients can send to the next repilca in the ring and switch from ONE
>> write/reads to QUORUM write/reads temporarily until the first replica
>> becomes available again. =A0QUORUM is required since there could be some
>> replicas that were not updated after the first replica went down.
>>
>> Will this work? =A0The goal is to have strong consistency with a read/wr=
ite
>> consistency level as low as possible while secondarily a network perform=
ance
>> boost.
>
>


--=20
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com