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 > >
