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 between 2 data centers that are separated by a large body of water, like NY to London, where you've got a 25ms ping, roughly. Perfectly consistent, at scale, without downtime, when a shark bites the undersea cable you're using? No, not happening. On Thu, Oct 8, 2015 at 5:05 PM Renato Perini <renato.per...@gmail.com> wrote: > 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 > > 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 because you probably can't even define what > that is. > > On Thu, Oct 8, 2015 at 4:17 PM Renato Perini <renato.per...@gmail.com> > wrote: > >> How the two things can fit together? >> Cassandra endorses the AP side of the CAP theorem. So how Cassandra can >> deliver realtime consistent data? >> AFAIK, choosing a consistency level equals to ALL can be a huge >> performance hit for C*, so, please, explain me why I should choose C* >> for realtime data >> that should be consistent across reads after the data has been written. >> >> Thank you. >> >> >
