git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improve the performance of CAS


Hey all,

Before we go bananas, let's see if Sylvain, the primary author of the
original patch, has the opportunity to chime with some explanatory notes or
other guidance. There may be some subtle points or considerations that are
not obvious, and I'd hate to lose that context.

Thanks,

-Jason

On Wed, May 16, 2018 at 2:57 PM, Ariel Weisberg <ariel@xxxxxxxxxxx> wrote:

> 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 <kohlisankalp@xxxxxxxxx>
> > 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.hanna1234@xxxxxxxxx>
> > > 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 <dikang85@xxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > > > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Dikang
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>
>