pretty straightforward but some minor fixes
This commit is contained in:
Liz Snyder
parent
9dedb7ed92
commit
8d9c0ebf30
|
|
@ -5,11 +5,11 @@ nav_order: 51
|
|||
has_children: true
|
||||
---
|
||||
|
||||
# Asynchronous Search
|
||||
# Asynchronous search
|
||||
|
||||
Searching large volumes of data can take a long time, especially if you're searching across warm nodes or multiple remote clusters.
|
||||
|
||||
Asynchronous search lets you run search requests that run in the background. You can monitor the progress of these searches and get back partial results as they become available. After the search finishes, you can save the results to examine at a later time.
|
||||
Asynchronous search in OpenSearch lets you send search requests that run in the background. You can monitor the progress of these searches and get back partial results as they become available. After the search finishes, you can save the results to examine at a later time.
|
||||
|
||||
## REST API
|
||||
|
||||
|
|
@ -23,9 +23,9 @@ You can specify the following options.
|
|||
|
||||
Options | Description | Default value | Required
|
||||
:--- | :--- |:--- |:--- |
|
||||
`wait_for_completion_timeout` | Specifies the amount of time that you plan to wait for the results. You can see whatever results you get within this time just like in a normal search. You can poll the remaining results based on an ID. The maximum value is 300 seconds. | 1 second | No
|
||||
`keep_on_completion` | Specifies whether you want to save the results in the cluster after the search is complete. You can examine the stored results at a later time. | `false` | No
|
||||
`keep_alive` | Specifies the amount of time that the result is saved in the cluster. For example, `2d` means that the results are stored in the cluster for 48 hours. The saved search results are deleted after this period or if the search is cancelled. Note that this includes the query execution time. If the query overruns this time, the process cancels this query automatically. | 12 hours | No
|
||||
`wait_for_completion_timeout` | The amount of time that you plan to wait for the results. You can see whatever results you get within this time just like in a normal search. You can poll the remaining results based on an ID. The maximum value is 300 seconds. | 1 second | No
|
||||
`keep_on_completion` | Whether you want to save the results in the cluster after the search is complete. You can examine the stored results at a later time. | `false` | No
|
||||
`keep_alive` | The amount of time that the result is saved in the cluster. For example, `2d` means that the results are stored in the cluster for 48 hours. The saved search results are deleted after this period or if the search is canceled. Note that this includes the query execution time. If the query overruns this time, the process cancels this query automatically. | 12 hours | No
|
||||
|
||||
#### Sample request
|
||||
|
||||
|
|
|
|||
|
|
@ -24,9 +24,9 @@ If these roles don’t meet your needs, mix and match individual asynchronous se
|
|||
|
||||
Use backend roles to configure fine-grained access to asynchronous searches based on roles. For example, users of different departments in an organization can view asynchronous searches owned by their own department.
|
||||
|
||||
First, make sure that your users have the appropriate [backend roles](../../security/access-control/). Backend roles usually come from an [LDAP server](../../security/configuration/ldap/) or [SAML provider](../../security/configuration/saml/). However, if you use the internal user database, you can use the REST API to [add them manually](../../security/access-control/api/#create-user).
|
||||
First, make sure your users have the appropriate [backend roles](../../security/access-control/). Backend roles usually come from an [LDAP server](../../security/configuration/ldap/) or [SAML provider](../../security/configuration/saml/). However, if you use the internal user database, you can use the REST API to [add them manually](../../security/access-control/api/#create-user).
|
||||
|
||||
Now when users view asynchronous search resources in OpenSearch Dashboards (or make REST API calls), they only see asynchronous searches that are submitted by users who have a subset of the backend role.
|
||||
Now when users view asynchronous search resources in OpenSearch Dashboards (or make REST API calls), they only see asynchronous searches submitted by users who have a subset of the backend role.
|
||||
For example, consider two users: `judy` and `elon`.
|
||||
|
||||
`judy` has an IT backend role:
|
||||
|
|
@ -73,4 +73,4 @@ Because they have different backend roles, an asynchronous search submitted by `
|
|||
|
||||
`judy` needs to have at least the superset of all roles that `elon` has to see `elon`'s asynchronous searches.
|
||||
|
||||
For example, if `judy` has five backend roles and `elon` one has one of these roles, then `judy` can see asynchronous searches submitted by `elon`, but `elon` can’t see the asynchronous searches submitted by `judy`. This means that `judy` can perform GET and DELETE operations on asynchronous searches that are submitted by `elon`, but not the reverse.
|
||||
For example, if `judy` has five backend roles and `elon` has one of these roles, then `judy` can see asynchronous searches submitted by `elon`, but `elon` can’t see the asynchronous searches submitted by `judy`. This means that `judy` can perform GET and DELETE operations on asynchronous searches submitted by `elon`, but not the reverse.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ has_children: false
|
|||
|
||||
The OpenSearch CLI command line interface (opensearch-cli) lets you manage your OpenSearch cluster from the command line and automate tasks.
|
||||
|
||||
Currently, opensearch-cli supports the [Anomaly Detection](../ad/) and [k-NN](../knn/) plugins, along with arbitrary REST API paths. Among other things, you can use opensearch-cli create and delete detectors, start and stop them, and check k-NN statistics.
|
||||
Currently, opensearch-cli supports the [Anomaly Detection](../ad/) and [k-NN](../knn/) plugins, along with arbitrary REST API paths. Among other things, you can use opensearch-cli to create and delete detectors, start and stop them, and check k-NN statistics.
|
||||
|
||||
Profiles let you easily access different clusters or sign requests with different credentials. opensearch-cli supports unauthenticated requests, HTTP basic signing, and IAM signing for Amazon Web Services.
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ opensearch-cli ad delete ecommerce-count-quantity --profile staging
|
|||
export PATH=$PATH:$(pwd)
|
||||
```
|
||||
|
||||
1. Check that the CLI is working properly:
|
||||
1. Confirm the CLI is working properly:
|
||||
|
||||
```bash
|
||||
opensearch-cli --version
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ The security plugin blocks the update by script operation (`POST <index>/_update
|
|||
|
||||
## Illegal reflective access operation in logs
|
||||
|
||||
This is a [known issue](https://github.com/opensearch-project/performance-analyzer/issues/21) with Performance Analyzer that shouldn't affect functionality.
|
||||
This is a known issue with Performance Analyzer that shouldn't affect functionality.
|
||||
|
||||
|
||||
## Multi-tenancy issues in OpenSearch Dashboards
|
||||
|
|
|
|||
Loading…
Reference in New Issue