Mike Percy created KUDU-2277:
--------------------------------
Summary: Deprecate replica selection in the KuduScanner
Key: KUDU-2277
URL: https://issues.apache.org/jira/browse/KUDU-2277
Project: Kudu
Issue Type: Improvement
Components: client
Affects Versions: 1.6.0
Reporter: Mike Percy
This ticket is to track deprecating the replica selection method in the Kudu
client API. I propose deprecating this and rendering the method non-functional,
and changing the effective default to "auto" instead of "leader" or "closest".
Here it is in the Java API:
[https://kudu.apache.org/releases/1.6.0/apidocs/org/apache/kudu/client/AbstractKuduScannerBuilder.html#replicaSelection-org.apache.kudu.client.ReplicaSelection-]
It would be better to replace this with scanner APIs that specify the
consistency guarantees desired and the performance tradeoffs as well. Something
like:
{code:java}
ScannerBuilder builder;
builder.minimumConsistencyLevel(READ_YOUR_WRITES);
builder.minimumIsolationLevel(MONOTONIC_ATOMIC_VIEW);
builder.performanceOptimization(LATENCY);
Scanner = builder.build();
{code}
The scanner would choose an appropriate implementation across the selected
dimensions to achieve the requires consistency / isolation levels along with
selecting replicas to account for the performance optimization hint. In the
case of something like READ_YOUR_WRITES + LATENCY but without the
MONOTONIC_ATOMIC_VIEW requirements, perhaps reading from the leader without
waiting would be sufficient. In other cases, when optimizing for THROUGHPUT, it
most likely makes sense to try to read from the closest follower.
In short, we are leaving optimizations and flexibility on the table by allowing
users to specify a replica selection policy, a tool that is hard for people to
understand how to use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
