Skip to content

Commit 28ae015

Browse files
committed
Docs: Informations about shard-aware LBPs
This commit also includes some changes that were omitted during older changes to LBP.
1 parent 48aa642 commit 28ae015

File tree

2 files changed

+20
-18
lines changed

2 files changed

+20
-18
lines changed

docs/source/load-balancing/load-balancing.md

+13-12
Original file line numberDiff line numberDiff line change
@@ -2,8 +2,8 @@
22

33
## Introduction
44

5-
The driver uses a load balancing policy to determine which node(s) to contact
6-
when executing a query. Load balancing policies implement the
5+
The driver uses a load balancing policy to determine which node(s) and shard(s)
6+
to contact when executing a query. Load balancing policies implement the
77
`LoadBalancingPolicy` trait, which contains methods to generate a load
88
balancing plan based on the query information and the state of the cluster.
99

@@ -12,12 +12,14 @@ being opened. For a node connection blacklist configuration refer to
1212
`scylla::transport::host_filter::HostFilter`, which can be set session-wide
1313
using `SessionBuilder::host_filter` method.
1414

15+
In this chapter, "target" will refer to a pair `<node, optional shard>`.
16+
1517
## Plan
1618

1719
When a query is prepared to be sent to the database, the load balancing policy
18-
constructs a load balancing plan. This plan is essentially a list of nodes to
20+
constructs a load balancing plan. This plan is essentially a list of targets to
1921
which the driver will try to send the query. The first elements of the plan are
20-
the nodes which are the best to contact (e.g. they might be replicas for the
22+
the targets which are the best to contact (e.g. they might be replicas for the
2123
requested data or have the best latency).
2224

2325
## Policy
@@ -84,17 +86,16 @@ first element of the load balancing plan is needed, so it's usually unnecessary
8486
to compute entire load balancing plan. To optimize this common case, the
8587
`LoadBalancingPolicy` trait provides two methods: `pick` and `fallback`.
8688

87-
`pick` returns the first node to contact for a given query, which is usually
88-
the best based on a particular load balancing policy. If `pick` returns `None`,
89-
then `fallback` will not be called.
89+
`pick` returns the first target to contact for a given query, which is usually
90+
the best based on a particular load balancing policy.
9091

91-
`fallback`, returns an iterator that provides the rest of the nodes in the load
92-
balancing plan. `fallback` is called only when using the initial picked node
93-
fails (or when executing speculatively).
92+
`fallback`, returns an iterator that provides the rest of the targets in the
93+
load balancing plan. `fallback` is called when using the initial picked
94+
target fails (or when executing speculatively) or when `pick` returned `None`.
9495

95-
It's possible for the `fallback` method to include the same node that was
96+
It's possible for the `fallback` method to include the same target that was
9697
returned by the `pick` method. In such cases, the query execution layer filters
97-
out the picked node from the iterator returned by `fallback`.
98+
out the picked target from the iterator returned by `fallback`.
9899

99100
### `on_query_success` and `on_query_failure`:
100101

scylla/src/transport/load_balancing/mod.rs

+7-6
Original file line numberDiff line numberDiff line change
@@ -41,16 +41,17 @@ pub struct RoutingInfo<'a> {
4141
/// (or when speculative execution is triggered).
4242
pub type FallbackPlan<'a> = Box<dyn Iterator<Item = (NodeRef<'a>, Shard)> + Send + Sync + 'a>;
4343

44-
/// Policy that decides which nodes to contact for each query.
44+
/// Policy that decides which nodes and shards to contact for each query.
4545
///
4646
/// When a query is prepared to be sent to ScyllaDB/Cassandra, a `LoadBalancingPolicy`
47-
/// implementation constructs a load balancing plan. That plan is a list of nodes to which
48-
/// the driver will try to send the query. The first elements of the plan are the nodes which are
47+
/// implementation constructs a load balancing plan. That plan is a list of
48+
/// targets (target is a node + an optional shard) to which
49+
/// the driver will try to send the query. The first elements of the plan are the targets which are
4950
/// the best to contact (e.g. they might have the lowest latency).
5051
///
51-
/// Most queries are send on the first try, so the query execution layer rarely needs to know more
52-
/// than one node from plan. To better optimize that case, `LoadBalancingPolicy` has two methods:
53-
/// `pick` and `fallback`. `pick` returns a first node to contact for a given query, `fallback`
52+
/// Most queries are sent on the first try, so the query execution layer rarely needs to know more
53+
/// than one target from plan. To better optimize that case, `LoadBalancingPolicy` has two methods:
54+
/// `pick` and `fallback`. `pick` returns the first target to contact for a given query, `fallback`
5455
/// returns the rest of the load balancing plan.
5556
///
5657
/// `fallback` is called not only if a send to `pick`ed node failed (or when executing

0 commit comments

Comments
 (0)