[
https://issues.apache.org/jira/browse/CASSANDRA-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479501#comment-16479501
]
Sylvain Lebresne commented on CASSANDRA-14448:
----------------------------------------------
bq. don't think that means we should prevent people who follow the rules from
getting better performance.
What are you talking about. Again, you can provide the specific {{CL}} used for
the commit, so no-one is forcing you to have strong synchronicity on that write
if you don't want to. Again, we *arlready largely support async commit*.
Typically, your example of DC having high latency between them is irrelevant in
the sense that you absolutely don't have to pay cross-DC latency on the commit
phase, you have that use as low a consistency level than {{ANY}}.
bq. Is that a documented supported behavior?
Well, documentation has never been the project strong suit, but allowing users
to tune the{{CL}} of the commit so they could trade slightly more latency on
writes for faster consistent reads *if they wants* was very much intentional.
> Improve the performance of CAS
> ------------------------------
>
> Key: CASSANDRA-14448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14448
> Project: Cassandra
> Issue Type: Improvement
> Components: Coordination
> Reporter: Dikang Gu
> Assignee: Dikang Gu
> Priority: Major
>
> I'm working on some performance improvements of the lightweight transitions
> (compare and set).
>
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
