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<[email protected]> wrote:
2009/7/14 Jonathan Ellis <[email protected]>
On Tue, Jul 14, 2009 at 8:33 AM, Mark Robson<[email protected]>
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
