Hi, I think you are looking at the right low hanging fruit. Cassandra deserves a better consensus protocol, but it's a very big project.
Regards, Ariel On Wed, May 16, 2018, at 5:51 PM, Dikang Gu wrote: > Cool, create a jira for it, > https://issues.apache.org/jira/browse/CASSANDRA-14448. I have a draft patch > working internally, will clean it up. > > The EPaxos is more complicated, could be a long term effort. > > Thanks > Dikang. > > On Wed, May 16, 2018 at 2:20 PM, sankalp kohli <kohlisank...@gmail.com> > wrote: > > > Hi, > > The idea of combining read with prepare sounds good. Regarding reducing > > the commit round trip, it is possible today by giving a lower consistency > > level for commit I think. > > > > Regarding EPaxos, it is a large change and will take longer to land. I > > think we should do this as it will help lower the latencies a lot. > > > > Thanks, > > Sankalp > > > > On Wed, May 16, 2018 at 2:15 PM, Jeremy Hanna <jeremy.hanna1...@gmail.com> > > wrote: > > > > > Hi Dikang, > > > > > > Have you seen Blake’s work on implementing egalitarian paxos or epaxos*? > > > That might be helpful for the discussion. > > > > > > Jeremy > > > > > > * https://issues.apache.org/jira/browse/CASSANDRA-6246 > > > > > > > On May 16, 2018, at 3:37 PM, Dikang Gu <dikan...@gmail.com> wrote: > > > > > > > > Hello C* developers, > > > > > > > > I'm working on some performance improvements of the lightweight > > > transitions > > > > (compare and set), I'd like to hear your thoughts about it. > > > > > > > > As you know, current CAS requires 4 round trips to finish, which is not > > > > efficient, especially in cross DC case. > > > > 1) Prepare > > > > 2) Quorum read current value > > > > 3) Propose new value > > > > 4) Commit > > > > > > > > I'm proposing the following improvements to reduce it to 2 round trips, > > > > which is: > > > > 1) Combine prepare and quorum read together, use only one round trip to > > > > decide the ballot and also piggyback the current value in response. > > > > 2) Propose new value, and then send out the commit request > > > asynchronously, > > > > so client will not wait for the ack of the commit. In case of commit > > > > failures, we should still have chance to retry/repair it through hints > > or > > > > following read/cas events. > > > > > > > > After the improvement, we should be able to finish the CAS operation > > > using > > > > 2 rounds trips. There can be following improvements as well, and this > > can > > > > be a start point. > > > > > > > > What do you think? Did I miss anything? > > > > > > > > Thanks > > > > Dikang > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > -- > Dikang --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
