Re: Realtime data and (C)AP

The DataStax Java driver is based on Netty and is non blocking; if you do any CQL work you should look into it. At ProtectWise we use it with high write volumes from Scala/Akka with great success. We have a thin Scala wrapper around the Java driver that makes it act more Scalaish (eg, Scala

Re: Realtime data and (C)AP

Obviously QUORUM_OR_ONE is in general no better than ONE. However we hardly EVER fail back to ONE, and we are making a conscious choice. I’m okay with hiding it if it is too tempting, but for insert/append only workloads without deletes or TTL, it is a perfectly good trade off. Why not just use

Re: Realtime data and (C)AP

Downgrading Consistency Policy suffers from effectively being the downgraded consistency policy aka CL one. I think it's helpful to remember that Consistency Level is effectively a contract on your consistency, if you do "quorum or one" you're basically CL ONE. Think of it this way, CL ONE usually

Re: Realtime data and (C)AP

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 wrote: > > Hi Graham, > > I've used the Java

Re: Realtime data and (C)AP

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

Re: Realtime data and (C)AP

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

Re: Realtime data and (C)AP

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

Re: Realtime data and (C)AP

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

Re: Realtime data and (C)AP

On Fri, Oct 9, 2015 at 2:27 AM, Steve Robenalt 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

Re: Realtime data and (C)AP

Your options are 1. Read & write at quorum 2. Recognize that, in general, if you've got a real need for Cassandra, your data is out of date almost immediately after you've read it no matter what guarantee your DB gives you, so you might as well just forget about ever getting the "right" answer

Re: Realtime data and (C)AP

Renato, please watch this netflix video on consistency: http://www.planetcassandra.org/blog/a-netflix-experiment-eventual-consistency-hopeful-consistency-by-christos-kalantzis/ All the best, [image: datastax_logo.png] Sebastián Estévez Solutions Architect | 954 905

Re: Realtime data and (C)AP

I'm asking because the DataStax DS-201 course states that C* is an ideal fit for messaging applications. What I'm not understanding? :-) Messaging applications generally must be totally consistent, expecially real-time ones. Il 09/10/2015 01:34, Jonathan Haddad ha scritto: Your options are

Re: Realtime data and (C)AP

Hi Renato, Your original statement is not entirely correct, and the video Sebastian is suggesting can probably help make it clearer. It's not that Cassandra favors the AP side of CAP. It more that Cassandra allows you to tune what level of consistency you require. Cassandra does force you to

Re: Realtime data and (C)AP

Most of the things that people thing are "totally consistent" or instant are in reality, not. Examples include banks (inconsistent by days), the time it takes for light to travel around the earth (~150ms), and messaging (email can take quite minutes). Try to imagine being perfectly consistent