[
https://issues.apache.org/jira/browse/CASSANDRA-13645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16067530#comment-16067530
]
Jason Brown commented on CASSANDRA-13645:
-----------------------------------------
In the current system, as we cannot guarantee (i.e. force) the consistency
level that users write with, we can't make optimization assumptions for the
read path wrt strong consistency. Meaning, if a user issues a read with your
optimized CL, we can't know if we can take the optimized path as we don't know
how the data was written. If a system like Aurora enforces those CL constraints
at write time, then, yes, you can safely know you can take the optimization. If
a user has a cluster with RF=4, issues a write at CL.ONE, then issues a read
with CL.QUORUM, we cannot guarantee strong consistency.
tbh, I'm reticent about changing the semantics of existing ConsistencyLevels.
[~brandon.williams]'s suggestion is not unreasonable. Another alternative is
creating CL.OPTIMZED_QUORUM (pick your name), which knows how to perform the
best optimizations for read and write, regardless of RF, with the expectation
that the user *always* uses this CL for interacting with the table (similar to
the expectation we have for CAS). Special care may need to be taken in the face
of cluster membership changes, and so on.
> Optimize the number of replicas required in Quorum read/write
> -------------------------------------------------------------
>
> Key: CASSANDRA-13645
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13645
> Project: Cassandra
> Issue Type: Improvement
> Components: Coordination
> Reporter: Dikang Gu
> Assignee: Dikang Gu
> Fix For: 4.x
>
>
> Currently, for C* read/write requests with quorum consistent level, number of
> replicas required for quorum write is W=N/2+1, and number of replicas
> required for quorum read is R=N/2+1 as well.
> It works fine in odd number of replicas case, which R + W = N + 1, but in
> even number of replicas case, like RF=4, 6, 8, the R+W = N + 2, which means
> we are having two overlapping nodes in read/write requests, which is not
> necessary. It can not provide strong consistency, but will hurts P99 read
> latency a lot (2X in our production cluster).
> In a lot of other database, like Amazon Aurora, they use W = N/2 + 1 and R =
> N/2 for quorum requests, which will provide enough strong consistency, but
> talk to one less replica in read path. "We use a quorum model with 6 votes (V
> = 6), a write quorum of 4/6 (Vw = 4), and a read quorum of 3/6 (Vr = 3)."
> I propose we do the same optimization, change read quorum to talk to N/2
> replicas, which should reduce the read latency for quorum read in general.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
