incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Revelle <mreve...@gmail.com>
Subject Re: Scaling from 1 to x (was: one server or more servers?)
Date Tue, 14 Jul 2009 14:33:41 GMT
Is that documented anywhere?  I've been wondering how block_for should  
be used...

On Jul 14, 2009, at 10:26 AM, Jonathan Ellis wrote:

> 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