* Adds search backpressure documentation Signed-off-by: Fanit Kolchina <[email protected]> * Updated response Signed-off-by: Fanit Kolchina <[email protected]> * Removed last cancelled task Signed-off-by: Fanit Kolchina <[email protected]> * Fixed typo Signed-off-by: Fanit Kolchina <[email protected]> * Incorporated tech review feedback Signed-off-by: Fanit Kolchina <[email protected]> * Incorporated doc review feedback Signed-off-by: Fanit Kolchina <[email protected]> * Update _opensearch/search-backpressure.md Co-authored-by: Nate Bower <[email protected]> * Apply suggestions from code review Co-authored-by: Nate Bower <[email protected]> * Rewording Signed-off-by: Fanit Kolchina <[email protected]> * Minor rewording for clarity Signed-off-by: Fanit Kolchina <[email protected]> Signed-off-by: Fanit Kolchina <[email protected]> Co-authored-by: Nate Bower <[email protected]>
1.3 KiB
layout, title, nav_order, has_children, redirect_from
| layout | title | nav_order | has_children | redirect_from | |
|---|---|---|---|---|---|
| default | Segment replication | 64 | true |
|
Segment replication
Segment replication is an experimental feature with OpenSearch 2.3. Therefore, we do not recommend the use of segment replication in a production environment. For updates on the progress of segment replication or if you want leave feedback that could help improve the feature, see the Segment replication git issue. {: .warning}
With segment replication, segment files are copied across shards instead of documents being indexed on each shard copy. This improves indexing throughput and lowers resource utilization at the expense of increased network utilization.
As an experimental feature, segment replication will be behind a feature flag and must be enabled on each node of a cluster and pass a new setting during index creation. {: .note }
Potential use cases
- Users who have high write loads but do not have high search requirements and are comfortable with longer refresh times.
- Users with very high loads who want to add new nodes, as you do not need to index all nodes when adding a new node to the cluster.
This is the first step in a series of features designed to decouple reads and writes in order to lower compute costs.