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 >
