[
https://issues.apache.org/jira/browse/KUDU-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Percy updated KUDU-2277:
-----------------------------
Description:
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.
was:
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.
> 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
> Priority: Major
>
> 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)
