Most of our writes are not user facing so local_quorum is good... We also read at local_quorum because we prefer guaranteed consistency... But we very quickly fall back to local_one in the cases where some data fast is better than a failure. Currently we do that on a per read basis but we could I suppose detect a pattern or just look at the gossip to decide to go en masse into a degraded read mode
Sent from my iPhone > On Oct 9, 2015, at 5:39 PM, Steve Robenalt <sroben...@highwire.org> wrote: > > Hi Brice, > > I agree with your nit-picky comment, particularly with respect to the OP's > emphasis, but there are many cases where read at ONE is sufficient and > performance is "better enough" to justify the possibility of a wrong result. > As with anything Cassandra, it's highly dependent on the nature of the > workload. > > Steve > > >> On Fri, Oct 9, 2015 at 12:36 PM, Brice Dutheil <brice.duth...@gmail.com> >> wrote: >>> On Fri, Oct 9, 2015 at 2:27 AM, Steve Robenalt <sroben...@highwire.org> >>> wrote: >>> >>> In general, if you write at QUORUM and read at ONE (or LOCAL variants >>> thereof if you have multiple data centers), your apps will work well >>> despite the theoretical consistency issues. >> >> Nit-picky comment : if consistency is something important then reading at >> QUORUM is important. If read is ONE then the read operation may not see >> important update. The safest option is QUORUM for both write and read. Then >> depending on the business or feature the consistency may be tuned. >> >> — Brice >> > > > > -- > Steve Robenalt > Software Architect > sroben...@highwire.org > (office/cell): 916-505-1785 > > HighWire Press, Inc. > 425 Broadway St, Redwood City, CA 94063 > www.highwire.org > > Technology for Scholarly Communication
