[DOCS] Add diagrams to cross-cluster search documentation (#45569)
This commit is contained in:
parent
7119e54be5
commit
c75fd40f2c
Binary file not shown.
After Width: | Height: | Size: 68 KiB |
Binary file not shown.
After Width: | Height: | Size: 68 KiB |
Binary file not shown.
After Width: | Height: | Size: 72 KiB |
Binary file not shown.
After Width: | Height: | Size: 71 KiB |
Binary file not shown.
After Width: | Height: | Size: 63 KiB |
Binary file not shown.
After Width: | Height: | Size: 63 KiB |
|
@ -280,38 +280,90 @@ GET /cluster_one:twitter,cluster_two:twitter,twitter/_search <1>
|
||||||
<1> The `clusters` section indicates that one cluster was unavailable and got skipped
|
<1> The `clusters` section indicates that one cluster was unavailable and got skipped
|
||||||
|
|
||||||
[float]
|
[float]
|
||||||
[[ccs-reduction]]
|
[[ccs-works]]
|
||||||
=== {ccs-cap} reduction phase
|
=== How {ccs} works
|
||||||
|
Because {ccs} involves sending requests to remote clusters, any network delays
|
||||||
|
can impact search speed. To avoid slow searches, {ccs} offers two options for
|
||||||
|
handling network delays:
|
||||||
|
|
||||||
{ccs-cap} (CCS) requests can be executed in two ways:
|
<<ccs-min-roundtrips,Minimize network roundtrips>>::
|
||||||
|
By default, {es} reduces the number of network roundtrips between remote
|
||||||
|
clusters. This reduces the impact of network delays on search speed. However,
|
||||||
|
{es} can't reduce network roundtrips for large search requests, such as those
|
||||||
|
including a <<request-body-search-scroll, scroll>> or
|
||||||
|
<<request-body-search-inner-hits,inner hits>>.
|
||||||
|
+
|
||||||
|
See <<ccs-min-roundtrips>> to learn how this option works.
|
||||||
|
|
||||||
- the CCS coordinating node minimizes network round-trips by sending one search
|
<<ccs-unmin-roundtrips, Don't minimize network roundtrips>>::
|
||||||
request to each cluster. Each cluster performs the search independently,
|
For search requests that include a scroll or inner hits, {es} sends multiple
|
||||||
reducing and fetching results. Once the CCS node has received all the
|
outgoing and ingoing requests to each remote cluster. You can also choose this
|
||||||
responses, it performs another reduction and returns the relevant results back
|
option by setting the <<search,search>> API's
|
||||||
to the user. This strategy is beneficial when there is network latency between
|
<<ccs-minimize-roundtrips,`ccs_minimize_roundtrips`>> parameter to `false`.
|
||||||
the CCS coordinating node and the remote clusters involved, which is typically
|
While typically slower, this approach may work well for networks with low
|
||||||
the case. A single request is sent to each remote cluster, at the cost of
|
latency.
|
||||||
retrieving `from` + `size` already fetched results. This is the default
|
+
|
||||||
strategy, used whenever possible. In case a scroll is provided, or inner hits
|
See <<ccs-unmin-roundtrips>> to learn how this option works.
|
||||||
are requested as part of field collapsing, this strategy is not supported hence
|
|
||||||
network round-trips cannot be minimized and the following strategy is used
|
|
||||||
instead.
|
|
||||||
|
|
||||||
- the CCS coordinating node sends a <<search-shards,search shards>> request to
|
|
||||||
each remote cluster, in order to collect information about their corresponding
|
|
||||||
remote indices involved in the search request and the shards where their data
|
|
||||||
is located. Once each cluster has responded to such request, the search
|
|
||||||
executes as if all shards were part of the same cluster. The coordinating node
|
|
||||||
sends one request to each shard involved, each shard executes the query and
|
|
||||||
returns its own results which are then reduced (and fetched, depending on the
|
|
||||||
<<request-body-search-search-type, search type>>) by the CCS coordinating node.
|
|
||||||
This strategy may be beneficial whenever there is very low network latency
|
|
||||||
between the CCS coordinating node and the remote clusters involved, as it
|
|
||||||
treats all shards the same, at the cost of sending many requests to each remote
|
|
||||||
cluster, which is problematic in presence of network latency.
|
|
||||||
|
|
||||||
The <<search-request-body, search API>> supports the `ccs_minimize_roundtrips`
|
|
||||||
parameter, which defaults to `true` and can be set to `false` in case
|
|
||||||
minimizing network round-trips is not desirable.
|
|
||||||
|
|
||||||
|
[float]
|
||||||
|
[[ccs-min-roundtrips]]
|
||||||
|
==== Minimize network roundtrips
|
||||||
|
|
||||||
|
Here's how {ccs} works when you minimize network roundtrips.
|
||||||
|
|
||||||
|
. You send a {ccs} request to your local cluster. A coordinating node in that
|
||||||
|
cluster receives and parses the request.
|
||||||
|
+
|
||||||
|
image:images/ccs/ccs-min-roundtrip-client-request.png[]
|
||||||
|
|
||||||
|
. The coordinating node sends a single search request to each cluster, including
|
||||||
|
its own. Each cluster performs the search request independently.
|
||||||
|
+
|
||||||
|
image:images/ccs/ccs-min-roundtrip-cluster-search.png[]
|
||||||
|
|
||||||
|
. Each remote cluster sends its search results back to the coordinating node.
|
||||||
|
+
|
||||||
|
image:images/ccs/ccs-min-roundtrip-cluster-results.png[]
|
||||||
|
|
||||||
|
. After collecting results from each cluster, the coordinating node returns the
|
||||||
|
final results in the {ccs} response.
|
||||||
|
+
|
||||||
|
image:images/ccs/ccs-min-roundtrip-client-response.png[]
|
||||||
|
|
||||||
|
[float]
|
||||||
|
[[ccs-unmin-roundtrips]]
|
||||||
|
==== Don't minimize network roundtrips
|
||||||
|
|
||||||
|
Here's how {ccs} works when you don't minimize network roundtrips.
|
||||||
|
|
||||||
|
. You send a {ccs} request to your local cluster. A coordinating node in that
|
||||||
|
cluster receives and parses the request.
|
||||||
|
+
|
||||||
|
image:images/ccs/ccs-min-roundtrip-client-request.png[]
|
||||||
|
|
||||||
|
. The coordinating node sends a <<search-shards,search shards>> API request to
|
||||||
|
each remote cluster.
|
||||||
|
+
|
||||||
|
image:images/ccs/ccs-min-roundtrip-cluster-search.png[]
|
||||||
|
|
||||||
|
. Each remote cluster sends its response back to the coordinating node.
|
||||||
|
This response contains information about the indices and shards the {ccs}
|
||||||
|
request will be executed on.
|
||||||
|
+
|
||||||
|
image:images/ccs/ccs-min-roundtrip-cluster-results.png[]
|
||||||
|
|
||||||
|
. The coordinating node sends a search request to each shard, including those in
|
||||||
|
its own cluster. Each shard performs the search request independently.
|
||||||
|
+
|
||||||
|
image:images/ccs/ccs-dont-min-roundtrip-shard-search.png[]
|
||||||
|
|
||||||
|
. Each shard sends its search results back to the coordinating node.
|
||||||
|
+
|
||||||
|
image:images/ccs/ccs-dont-min-roundtrip-shard-results.png[]
|
||||||
|
|
||||||
|
. After collecting results from each cluster, the coordinating node returns the
|
||||||
|
final results in the {ccs} response.
|
||||||
|
+
|
||||||
|
image:images/ccs/ccs-min-roundtrip-client-response.png[]
|
||||||
|
|
|
@ -813,3 +813,7 @@ See <<getting-started-search>>.
|
||||||
[role="exclude", id="getting-started-conclusion"]
|
[role="exclude", id="getting-started-conclusion"]
|
||||||
=== Conclusion
|
=== Conclusion
|
||||||
See <<getting-started-next-steps>>.
|
See <<getting-started-next-steps>>.
|
||||||
|
|
||||||
|
[role="exclude",id="ccs-reduction"]
|
||||||
|
=== {ccs-cap} reduction
|
||||||
|
See <<ccs-works>>.
|
|
@ -113,6 +113,7 @@ And here is a sample response:
|
||||||
reduce the memory overhead per search request if the potential number of
|
reduce the memory overhead per search request if the potential number of
|
||||||
shards in the request can be large.
|
shards in the request can be large.
|
||||||
|
|
||||||
|
[[ccs-minimize-roundtrips]]
|
||||||
`ccs_minimize_roundtrips`::
|
`ccs_minimize_roundtrips`::
|
||||||
|
|
||||||
Defaults to `true`. Set to `false` to disable minimizing network round-trips
|
Defaults to `true`. Set to `false` to disable minimizing network round-trips
|
||||||
|
|
Loading…
Reference in New Issue