[
https://issues.apache.org/jira/browse/KUDU-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shenxingwuying updated KUDU-3382:
---------------------------------
Description:
The next 3 days, I'll fix the idea of the issue.
h1.
h1. Background && Motivation
Java client has supported two replica selective strategies:
{{public enum ReplicaSelection
{ LEADER_ONLY, CLOSEST_REPLICA }
}}
LEADER_ONLY can provide a strong consistency read.
Closest replica can reduce brandwidth cost and speed scan but the data may be
not the latest. Some users may want to both advantages.
h1. Problem Analysis
h2. linearizability read
If kudu need strong consistency read(linearizability read), read leader is not
enough, because double leader may be exist at a very small period time. During
that time, it's not liearizability read. So kudu should avoid double leader at
any time, pay the corresponding cost is no leader at a small time. Kudu should
make a choice. For user usally need linearizability, so I think kudu should
support it. During a very small time no leader's unavailability can avoid by
client's fault tolerance.
{{The problem can talk about at another issue, that's a sub problem.}}
{{At this I view it no problem by read leader.}}
h2.
h1. Solution
At Raft, there is a scheme for the scene.
Kudu's raft implements is a strong leader, leader's state machine is not older
than followers, and only timeout/ leader transfer can switch leader. About
this, someone can make sure it or I can do a experiment to prove it.
Suppose kudu read leader is linearizability, we can trust the leader's result.
# 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.
# 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(committed_opid) >= the opid.
At follower, I want to use Read Index.
h1. My conclusions
Kudu can support read followers and keep strong consistency(linearizability).
I will create another issue to talk about linearizability read from leader.
was:
h1. Background && Motivation
Java client has supported two replica selective strategies:
{{public enum ReplicaSelection
{ LEADER_ONLY, CLOSEST_REPLICA }
}}
LEADER_ONLY can provide a strong consistency read.
Closest replica can reduce brandwidth cost and speed scan but the data may be
not the latest. Some users may want to both advantages.
h1. Problem Analysis
h2. linearizability read
If kudu need strong consistency read(linearizability read), read leader is not
enough, because double leader may be exist at a very small period time. During
that time, it's not liearizability read. So kudu should avoid double leader at
any time, pay the corresponding cost is no leader at a small time. Kudu should
make a choice. For user usally need linearizability, so I think kudu should
support it. During a very small time no leader's unavailability can avoid by
client's fault tolerance.
{{The problem can talk about at another issue, that's a sub problem.}}
{{At this I view it no problem by read leader.}}
h2.
h1. Solution
At Raft, there is a scheme for the scene.
Kudu's raft implements is a strong leader, leader's state machine is not older
than followers, and only timeout/ leader transfer can switch leader. About
this, someone can make sure it or I can do a experiment to prove it.
Suppose kudu read leader is linearizability, we can trust the leader's result.
# 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.
# 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(committed_opid) >= the opid.
At follower, I want to use Read Index.
h1. My conclusions
Kudu can support read followers and keep strong consistency(linearizability).
I will create another issue to talk about linearizability read from leader.
> 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
>
> The next 3 days, I'll fix the idea of the issue.
> h1.
> h1. Background && Motivation
> Java client has supported two replica selective strategies:
>
> {{public enum ReplicaSelection
> { LEADER_ONLY, CLOSEST_REPLICA }
> }}
> LEADER_ONLY can provide a strong consistency read.
> Closest replica can reduce brandwidth cost and speed scan but the data may be
> not the latest. Some users may want to both advantages.
> h1. Problem Analysis
> h2. linearizability read
> If kudu need strong consistency read(linearizability read), read leader is
> not enough, because double leader may be exist at a very small period time.
> During that time, it's not liearizability read. So kudu should avoid double
> leader at any time, pay the corresponding cost is no leader at a small time.
> Kudu should make a choice. For user usally need linearizability, so I think
> kudu should support it. During a very small time no leader's unavailability
> can avoid by client's fault tolerance.
>
> {{The problem can talk about at another issue, that's a sub problem.}}
> {{At this I view it no problem by read leader.}}
> h2.
> h1. Solution
> At Raft, there is a scheme for the scene.
> Kudu's raft implements is a strong leader, leader's state machine is not
> older than followers, and only timeout/ leader transfer can switch leader.
> About this, someone can make sure it or I can do a experiment to prove it.
> Suppose kudu read leader is linearizability, we can trust the leader's result.
> # 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.
> # 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(committed_opid) >= the opid.
> At follower, I want to use Read Index.
> h1. My conclusions
> Kudu can support read followers and keep strong consistency(linearizability).
>
> I will create another issue to talk about linearizability read from leader.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
