[
https://issues.apache.org/jira/browse/KUDU-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shenxingwuying updated KUDU-3382:
---------------------------------
Description:
h1. Background && Motivation
Java client has supported two replica selective strategies:
{code:java}
public enum ReplicaSelection {
LEADER_ONLY,
CLOSEST_REPLICA
} {code}
LEADER_ONLY can provide a strong consistency read.
Closest replica can reduce brandwidth cost and speeding up scan, corresponding
to the data may be not the latest. Some users may want to both advantages.
h1. Solution
We can achieve the aim by read follower, reach the effect as read leader.
At Raft, there is serveral schemes for this. For examples:
# Read Log, read request is also duriable to wal by raft. The method can solve
the problem but it's performance (read and write) is worse, so we abandon it.
# Read Index. If leader, scan directly. If follower, follower should request
to leader to get last_committed_opid then wait local replica's apply opid reach
the opid, of course the wait time should be a limited time.
At followers, Read Index is better. More details can be talk.
Another issue (https://issues.apache.org/jira/browse/KUDU-3383) will talk about
read leaders to achieve the linearizability read.
was:
h1. Background && Motivation
Java client has supported two replica selective strategies:
{code:java}
public enum ReplicaSelection {
LEADER_ONLY,
CLOSEST_REPLICA
} {code}
LEADER_ONLY can provide a strong consistency read.
Closest replica can reduce brandwidth cost and speeding up scan, corresponding
to the data may be not the latest. Some users may want to both advantages.
h1. Solution
We can achieve the aim by read follower, reach the effect as read leader.
At Raft, there is serveral schemes for this. For examples:
# Read Log, read request is also duriable to wal by raft. The method can solve
the problem but it's performance (read and write) is worse, so we abandon it.
# Read Index. If leader, scan directly. If follower, follower should request
to leader to get last_committed_opid then wait local replica's apply opid reach
the opid, of course the wait time should be a limited time.
At followers, Read Index is better. More details can be talk.
Another issue (https://issues.apache.org/jira/browse/KUDU-3382) will talk about
read leaders to achieve the linearizability read.
> About strong consistency read from followers
> ---------------------------------------------
>
> Key: KUDU-3382
> URL: https://issues.apache.org/jira/browse/KUDU-3382
> Project: Kudu
> Issue Type: Improvement
> Reporter: shenxingwuying
> Assignee: shenxingwuying
> Priority: Major
>
> h1. Background && Motivation
> Java client has supported two replica selective strategies:
> {code:java}
> public enum ReplicaSelection {
> LEADER_ONLY,
> CLOSEST_REPLICA
> } {code}
> LEADER_ONLY can provide a strong consistency read.
> Closest replica can reduce brandwidth cost and speeding up scan,
> corresponding to the data may be not the latest. Some users may want to both
> advantages.
> h1. Solution
> We can achieve the aim by read follower, reach the effect as read leader.
> At Raft, there is serveral schemes for this. For examples:
> # Read Log, read request is also duriable to wal by raft. The method can
> solve the problem but it's performance (read and write) is worse, so we
> abandon it.
> # Read Index. If leader, scan directly. If follower, follower should request
> to leader to get last_committed_opid then wait local replica's apply opid
> reach the opid, of course the wait time should be a limited time.
> At followers, Read Index is better. More details can be talk.
> Another issue (https://issues.apache.org/jira/browse/KUDU-3383) will talk
> about read leaders to achieve the linearizability read.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
