cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Sanderson <gra...@vast.com>
Subject Re: Realtime data and (C)AP
Date Sat, 10 Oct 2015 20:50:01 GMT
Cool - yeah we are still on astyanax mode drivers and our own built from scratch 100% non blocking
Scala driver that we used in akka like environments

Sent from my iPhone

> On Oct 10, 2015, at 12:12 AM, Steve Robenalt <srobenalt@highwire.org> wrote:
> 
> Hi Graham,
> 
> I've used the Java driver's DowngradingConsistencyRetryPolicy for that in cases where
it makes sense.
> 
> Ref: http://docs.datastax.com/en/drivers/java/2.1/com/datastax/driver/core/policies/DowngradingConsistencyRetryPolicy.html
> 
> Steve
> 
> 
> 
>> On Fri, Oct 9, 2015 at 6:06 PM, Graham Sanderson <graham@vast.com> wrote:
>> Actually maybe I'll open a JIRA issue for a (local)quorum_or_one consistency level...
It should be trivial to implement on server side with exist timeouts ... I'll need to check
the CQL protocol to see if there is a good place to indicate you didn't reach quorum (in time)
>> 
>> Sent from my iPhone
>> 
>>> On Oct 9, 2015, at 8:02 PM, Graham Sanderson <graham@vast.com> wrote:
>>> 
>>> 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 <srobenalt@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.dutheil@gmail.com>
wrote:
>>>>>> On Fri, Oct 9, 2015 at 2:27 AM, Steve Robenalt <srobenalt@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
>>>> srobenalt@highwire.org 
>>>> (office/cell): 916-505-1785
>>>> 
>>>> HighWire Press, Inc.
>>>> 425 Broadway St, Redwood City, CA 94063
>>>> www.highwire.org
>>>> 
>>>> Technology for Scholarly Communication
> 
> 
> 
> -- 
> Steve Robenalt 
> Software Architect
> srobenalt@highwire.org 
> (office/cell): 916-505-1785
> 
> HighWire Press, Inc.
> 425 Broadway St, Redwood City, CA 94063
> www.highwire.org
> 
> Technology for Scholarly Communication

Mime
View raw message