8000 docs: add link to flow parallelization by cristianmtr · Pull Request #3597 · jina-ai/serve · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

docs: add link to flow parallelization #3597

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 7, 2021
Merged

docs: add link to flow parallelization #3597

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7df3303
docs: add link to flow parallelization
cristianmtr Oct 6, 2021
74aa5ea
docs: more fixes for k8s
cristianmtr Oct 6, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 9 additions & 6 deletions docs/advanced/experimental/kubernetes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -235,6 +235,8 @@ In Jina we support two ways of scaling:
- **Replicas** can be used with any Executor type.
- **Shards** should only be used with Indexers, since they store a state.

Check {ref}`here <flow-parallelization>` for more information.

```{admonition} Important
:class: important
This page describes Jina's behavior with kubernetes deployment for now.
Expand Down Expand Up @@ -267,11 +269,12 @@ Sharding means splitting the content of an Indexer into several parts.
These parts are then put on different machines.
This is helpful in two situations:

- When the full data does not fit onto one machine.
- When the latency of a single request becomes too slow.
Then splitting the load across two or more machines yields better results.
- When the full data does not fit on one machine
- When the latency of a single request becomes too large.

Then splitting the load across two or more machines yields better results.

When you shard your index, the request handling usually differes for index and search requests:
When you shard your index, the request handling usually differs between index and search requests:

- Index (and update, delete) will just be handled by a single shard => `polling='any'`
- Search requests are handled by all shards => `polling='all'`
Expand All @@ -287,7 +290,7 @@ search_flow = Flow().add(name='ExecutorWithShards', shards=3, polling='all', use

Each shard of a search Flow returns one set of results for each query Document.
A merger Executor combines them afterwards.
You can use the pre-build [MatchMerger](https://hub.jina.ai/executor/mruax3k7) or define your own merger.
You can use the pre-built [MatchMerger](https://hub.jina.ai/executor/mruax3k7) or define your own merger.

```{admonition} Example
:class: example
Expand All @@ -301,6 +304,6 @@ After the merger there will be 200 results per query Document.
Combining both gives all the advantages mentioned above.
When deploying to kubernetes, Jina replicates each single shard.
Thus, shards can scale independently.
The data syncronisation across replicas must be handled by the respective Indexer.
The data synchronisation across replicas must be handled by the respective Indexer.
For more detailed see {ref}`Dump and rolling update <dump-rolling-restart>`.

3 changes: 2 additions & 1 deletion docs/fundamentals/flow/parallel.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
# Parallelization
(flow-parallelization)=
# Parallelization

## Intra parallelism via `needs`

Expand Down
0