We have CL.TWO. On Thu, Jun 8, 2017 at 10:03 PM, Dikang Gu <dikan...@gmail.com> wrote:
> So, for the quorum, what we really want is that there is one overlap among > the nodes in write path and read path. It actually was my assumption for a > long time that we need (N/2 + 1) for write and just need (N/2) for read, > because it's enough to provide the strong consistency. > > On Thu, Jun 8, 2017 at 7:47 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: > >> It would be a little weird to change the definition of QUORUM, which >> means majority, to mean something other than majority for a single use >> case. Sounds like you want to introduce a new CL, HALF. >> On Thu, Jun 8, 2017 at 7:43 PM Dikang Gu <dikan...@gmail.com> wrote: >> >>> Justin, what I suggest is that for QUORUM consistent level, the block >>> for write should be (num_replica/2)+1, this is same as today, but for read >>> request, we just need to access (num_replica/2) nodes, which should provide >>> enough strong consistency. >>> >>> Dikang. >>> >>> On Thu, Jun 8, 2017 at 7:38 PM, Justin Cameron <jus...@instaclustr.com> >>> wrote: >>> >>>> 2/4 for write and 2/4 for read would not be sufficient to achieve >>>> strong consistency, as there is no overlap. >>>> >>>> In your particular case you could potentially use QUORUM for write and >>>> TWO for read (or vice-versa) and still achieve strong consistency. If you >>>> add additional nodes in the future this would obviously no longer work. >>>> Also the benefit of this is dubious, since 3/4 nodes still need to be >>>> accessible to perform writes. I'd also guess that it's unlikely to provide >>>> any significant performance increase. >>>> >>>> Justin >>>> >>>> On Fri, 9 Jun 2017 at 12:29 Dikang Gu <dikan...@gmail.com> wrote: >>>> >>>>> Hello there, >>>>> >>>>> We have some use cases are doing consistent read/write requests, and >>>>> we have 4 replicas in that cluster, according to our setup. >>>>> >>>>> What's interesting to me is that, for both read and write quorum >>>>> requests, they are blocked for 4/2+1 = 3 replicas, so we are accessing 3 >>>>> (for write) + 3 (for reads) = 6 replicas in quorum requests, which is 2 >>>>> replicas more than 4. >>>>> >>>>> I think it's not necessary to have 2 overlap nodes in even replication >>>>> factor case. >>>>> >>>>> I suggest to change the `quorumFor(keyspace)` code, separate the case >>>>> for read and write requests, so that we can reduce one replica request in >>>>> read path. >>>>> >>>>> Any concerns? >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> -- >>>>> Dikang >>>>> >>>>> -- >>>> >>>> >>>> *Justin Cameron*Senior Software Engineer >>>> >>>> >>>> <https://www.instaclustr.com/> >>>> >>>> >>>> This email has been sent on behalf of Instaclustr Pty. Limited >>>> (Australia) and Instaclustr Inc (USA). >>>> >>>> This email and any attachments may contain confidential and legally >>>> privileged information. If you are not the intended recipient, do not copy >>>> or disclose its content, but please reply to this email immediately and >>>> highlight the error to the sender and then immediately delete the message. >>>> >>> >>> >>> >>> -- >>> Dikang >>> >>> > > > -- > Dikang > >
