incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Scaling from 1 to x (was: one server or more servers?)
Date Tue, 14 Jul 2009 14:26:13 GMT
There are several interesting values you can pass to block_for:

0: fire-and-forget.  minimizes latency when that is more important
than robustness
1: wait for at least one node to fully ack the write before returning
(the other replicas will be finished in the background)
N/2 + 1, where N is the number of replicas: this is a quorum write;
combined with quorum reads, it means you can tolerate up to N - (N/2 +
1) nodes failing before you can get inconsistent results.  (which is
usually better than no results at all.)
N: guarantees consistent reads without having to wait for a quorum, so
you trade write latency and availability (since the write will fail if
one of the target nodes is down) for 100% consistency and reduced read
latency

-Jonathan

On Tue, Jul 14, 2009 at 9:18 AM, Mark Robson<markxr@gmail.com> wrote:
>
>
> 2009/7/14 Jonathan Ellis <jbellis@gmail.com>
>>
>> On Tue, Jul 14, 2009 at 8:33 AM, Mark Robson<markxr@gmail.com> wrote:
>> > Cassandra doesn't provide the guarantees about the latest changes being
>> > available from any given node, so you can't really use it in such an
>> > application.
>> >
>> > I don't know if the "blocking" variants of the write operations make any
>> > more guarantees, if they do then it might be suitable.
>>
>> Yes, quorum write/read would work just fine here.
>
> Are those the type of writes which you get by setting the "block" parameter
> to 1?
>
> Mark
>

Mime
View raw message