iSharkFly-Docs
/
opensearch-docs-cn
mirror of https://github.com/iSharkFly-Docs/opensearch-docs-cn
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Adds Point in Time documentation (#1753) 

* Adds Point in Time documentation

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Added to security model

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Added new parameter descriptions

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Added space

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Spelled out PIT

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Incorporated tech review comments

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Changed total to time

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Fixed link

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Editing

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Incorporated tech review comments

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Incorporated review comments

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Incorporated doc review comments

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Incorporated editorial feedback

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Minor edits

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>
This commit is contained in:
kolchfa-aws 2022-11-04 09:11:38 -04:00 committed by GitHub
parent 371535aa94
commit f3a909db20
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 445 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
_api-reference/nodes-apis/nodes-stats.md
View File

@ -158,19 +158,22 @@ GET _nodes/stats/
"current" : 0
},
"search" : {
"open_contexts" : 0,
"query_total" : 194,
"query_time_in_millis" : 467,
"query_current" : 0,
"fetch_total" : 194,
"fetch_time_in_millis" : 143,
"fetch_current" : 0,
"scroll_total" : 0,
"scroll_time_in_millis" : 0,
"scroll_current" : 0,
"suggest_total" : 0,
"suggest_time_in_millis" : 0,
"suggest_current" : 0
"open_contexts": 4,
"query_total": 194,
"query_time_in_millis": 467,
"query_current": 0,
"fetch_total": 194,
"fetch_time_in_millis": 143,
"fetch_current": 0,
"scroll_total": 0,
"scroll_time_in_millis": 0,
"scroll_current": 0,
"point_in_time_total": 0,
"point_in_time_time_in_millis": 0,
"point_in_time_current": 0,
"suggest_total": 0,
"suggest_time_in_millis": 0,
"suggest_current": 0
},
"merges" : {
"current" : 0,
@ -648,6 +651,9 @@ get.<br>&nbsp;&nbsp;&nbsp;&nbsp;missing_total | Integer | The number of failed g
get.<br>&nbsp;&nbsp;&nbsp;&nbsp;missing_time_in_millis | Integer | The total time for all failed get operations, in milliseconds.
get.<br>&nbsp;&nbsp;&nbsp;&nbsp;current | Integer | The number of get operations that are currently running.
search | Object | Statistics about the search operations for the node.
search.<br>&nbsp;&nbsp;&nbsp;&nbsp;point_in_time_total | Integer | The total number of Point in Time contexts that have been created (completed and active) since the node last restarted.
search.<br>&nbsp;&nbsp;&nbsp;&nbsp;point_in_time_time_in_millis | Integer | The amount of time that Point in Time contexts have been held open since the node last restarted, in milliseconds.
search.<br>&nbsp;&nbsp;&nbsp;&nbsp;point_in_time_current | Integer | The number of Point in Time contexts currently open.
search.<br>&nbsp;&nbsp;&nbsp;&nbsp;open_contexts | Integer | The number of open search contexts.
search.<br>&nbsp;&nbsp;&nbsp;&nbsp;query_total | Integer | The total number of query operations.
search.<br>&nbsp;&nbsp;&nbsp;&nbsp;query_time_in_millis | Integer | The total time for all query operations, in milliseconds.

270
_opensearch/point-in-time-api.md Normal file
View File

@ -0,0 +1,270 @@
---
layout: default
title: Point in Time API
nav_order: 58
has_children: false
parent: Point in Time
---
# Point in Time API
Use the [Point in Time (PIT)]({{site.url}}{{site.baseurl}}/opensearch/point-in-time/) API to manage PITs.
---
#### Table of contents
- TOC
{:toc}
---
## Create a PIT
Introduced 2.4
{: .label .label-purple }
Creates a PIT. The `keep_alive` query parameter is required; it specifies how long to keep a PIT.
### Path and HTTP methods
```json
POST /<target_indexes>/_search/point_in_time?keep_alive=1h&routing=&expand_wildcards=&preference=
```
### Path parameters
Parameter | Data Type | Description
:--- | :--- | :---
target_indexes | String | The name(s) of the target index(es) for the PIT. May contain a comma-separated list or a wildcard index pattern.
### Query parameters
Parameter | Data Type | Description
:--- | :--- | :---
keep_alive | Time | The amount of time to keep the PIT. Required.
preference | String | The node or the shard used to perform the search. Optional. Default is random.
routing | String | Specifies to route search requests to a specific shard. Optional. Default is the document's `_id`.
expand_wildcards | String | The type of index that can match the wildcard pattern. Supports comma-separated values. Valid values are the following:<br>- `all`: Match any index or data stream, including hidden ones. <br>- `open`: Match open, non-hidden indexes or non-hidden data streams. <br>- `closed`: Match closed, non-hidden indexes or non-hidden data streams. <br>- `hidden`: Match hidden indexes or data streams. Must be combined with `open`, `closed` or both `open` and `closed`.<br>- `none`: No wildcard patterns are accepted.<br> Optional. Default is `open`.
allow_partial_pit_creation | Boolean | Specifies whether to create a PIT with partial failures. Optional. Default is `false`.
#### Sample request
```json
POST /my-index-1/_search/point_in_time?keep_alive=100m
```
#### Sample response
```json
{
"pit_id": "o463QQEPbXktaW5kZXgtMDAwMDAxFnNOWU43ckt3U3IyaFVpbGE1UWEtMncAFjFyeXBsRGJmVFM2RTB6eVg1aVVqQncAAAAAAAAAAAIWcDVrM3ZIX0pRNS1XejE5YXRPRFhzUQEWc05ZTjdyS3dTcjJoVWlsYTVRYS0ydwAA",
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
},
"creation_time": 1658146050064
}
```
### Response fields
Field | Data Type | Description
:--- | :--- | :---
pit_id | [Base64 encoded binary]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/binary) | The PIT ID.
creation_time | long | The time the PIT was created, in milliseconds since the epoch.
## Extend a PIT time
You can extend a PIT time by providing a `keep_alive` parameter in the `pit` object when you perform a search:
```json
GET /_search
{
"size": 10000,
"query": {
"match" : {
"user.id" : "elkbee"
}
},
"pit": {
"id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA==",
"keep_alive": "100m"
},
"sort": [
{"@timestamp": {"order": "asc", "format": "strict_date_optional_time_nanos"}},
{"_shard_doc": "desc"}
],
"search_after": [
"2021-05-20T05:30:04.832Z"
]
}
```
The `keep_alive` parameter in a search request is optional. It specifies the amount by which to extend the time to keep a PIT.
{: .note}
## List all PITs
Introduced 2.4
{: .label .label-purple }
Returns all PITs in the OpenSearch cluster.
### Cross-cluster behavior
The List All PITs API returns only local PITs or mixed PITs (PITs created in both local and remote clusters). It does not return fully remote PITs.
#### Sample request
```json
GET /_search/point_in_time/_all
```
#### Sample response
```json
{
"pits": [
{
"pit_id": "o463QQEPbXktaW5kZXgtMDAwMDAxFnNOWU43ckt3U3IyaFVpbGE1UWEtMncAFjFyeXBsRGJmVFM2RTB6eVg1aVVqQncAAAAAAAAAAAEWcDVrM3ZIX0pRNS1XejE5YXRPRFhzUQEWc05ZTjdyS3dTcjJoVWlsYTVRYS0ydwAA",
"creation_time": 1658146048666,
"keep_alive": 6000000
},
{
"pit_id": "o463QQEPbXktaW5kZXgtMDAwMDAxFnNOWU43ckt3U3IyaFVpbGE1UWEtMncAFjFyeXBsRGJmVFM2RTB6eVg1aVVqQncAAAAAAAAAAAIWcDVrM3ZIX0pRNS1XejE5YXRPRFhzUQEWc05ZTjdyS3dTcjJoVWlsYTVRYS0ydwAA",
"creation_time": 1658146050064,
"keep_alive": 6000000
}
]
}
```
### Response fields
Field | Data Type | Description
:--- | :--- | :---
pits | Array of JSON objects | The list of all PITs.
Each PIT object contains the following fields.
Field | Data Type | Description
:--- | :--- | :---
pit_id | [Base64 encoded binary]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/binary) | The PIT ID.
creation_time | long | The time the PIT was created, in milliseconds since the epoch.
keep_alive | long | The amount of time to keep the PIT, in milliseconds.
## Delete PITs
Introduced 2.4
{: .label .label-purple }
Deletes one, several, or all PITs. PITs are automatically deleted when the `keep_alive` time period elapses. However, to deallocate resources, you can delete a PIT using the Delete PIT API. The Delete PIT API supports deleting a list of PITs by ID or deleting all PITs at once.
### Cross-cluster behavior
The Delete PITs by ID API fully supports deleting cross-cluster PITs.
The Delete All PITs API deletes only local PITs or mixed PITs (PITs created in both local and remote clusters). It does not delete fully remote PITs.
#### Sample Request: Delete all PITs
```json
DELETE /_search/point_in_time/_all
```
If you want to delete one or several PITs, specify their PIT IDs in the request body.
### Request fields
Field | Data Type | Description
:--- | :--- | :---
pit_id | [Base64 encoded binary]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/binary) or an array of binaries | The PIT IDs of the PITs to be deleted. Required.
#### Sample request: Delete PITs by ID
```json
DELETE /_search/point_in_time
{
"pit_id": [
"o463QQEPbXktaW5kZXgtMDAwMDAxFkhGN09fMVlPUkVPLXh6MUExZ1hpaEEAFjBGbmVEZHdGU1EtaFhhUFc4ZkR5cWcAAAAAAAAAAAEWaXBPNVJtZEhTZDZXTWFFR05waXdWZwEWSEY3T18xWU9SRU8teHoxQTFnWGloQQAA",
"o463QQEPbXktaW5kZXgtMDAwMDAxFkhGN09fMVlPUkVPLXh6MUExZ1hpaEEAFjBGbmVEZHdGU1EtaFhhUFc4ZkR5cWcAAAAAAAAAAAIWaXBPNVJtZEhTZDZXTWFFR05waXdWZwEWSEY3T18xWU9SRU8teHoxQTFnWGloQQAA"
]
}
```
#### Sample response
For each PIT, the response contains a JSON object with a PIT ID and a `successful` field that specifies whether the deletion was successful. Partial failures are treated as failures.
```json
{
"pits": [
{
"successful": true,
"pit_id": "o463QQEPbXktaW5kZXgtMDAwMDAxFkhGN09fMVlPUkVPLXh6MUExZ1hpaEEAFjBGbmVEZHdGU1EtaFhhUFc4ZkR5cWcAAAAAAAAAAAEWaXBPNVJtZEhTZDZXTWFFR05waXdWZwEWSEY3T18xWU9SRU8teHoxQTFnWGloQQAA"
},
{
"successful": false,
"pit_id": "o463QQEPbXktaW5kZXgtMDAwMDAxFkhGN09fMVlPUkVPLXh6MUExZ1hpaEEAFjBGbmVEZHdGU1EtaFhhUFc4ZkR5cWcAAAAAAAAAAAIWaXBPNVJtZEhTZDZXTWFFR05waXdWZwEWSEY3T18xWU9SRU8teHoxQTFnWGloQQAA"
}
]
}
```
### Response fields
Field | Data Type | Description
:--- | :--- | :---
successful | Boolean | Whether the delete operation was successful.
pit_id | [Base64 encoded binary]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/binary) | The PIT ID of the PIT to be deleted.
## PIT segments
Introduced 2.4
{: .label .label-purple }
Similarly to the [CAT Segments API]({{site.url}}{{site.baseurl}}/api-reference/cat/cat-segments), the PIT Segments API provides low-level information about the disk utilization of a PIT by describing its Lucene segments. The PIT Segments API supports listing segment information of a specific PIT by ID or of all PITs at once.
#### Sample request: PIT segments of all PITs
```json
GET /_cat/pit_segments/_all
```
If you want to list segments for one or several PITs, specify their PIT IDs in the request body.
### Request fields
Field | Data Type | Description
:--- | :--- | :---
pit_id | [Base64 encoded binary]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/binary) or an array of binaries | The PIT IDs of the PITs whose segments are to be listed. Required.
#### Sample request: PIT segments of PITs by ID
```json
GET /_cat/pit_segments
{
"pit_id": [
"o463QQEPbXktaW5kZXgtMDAwMDAxFkhGN09fMVlPUkVPLXh6MUExZ1hpaEEAFjBGbmVEZHdGU1EtaFhhUFc4ZkR5cWcAAAAAAAAAAAEWaXBPNVJtZEhTZDZXTWFFR05waXdWZwEWSEY3T18xWU9SRU8teHoxQTFnWGloQQAA",
"o463QQEPbXktaW5kZXgtMDAwMDAxFkhGN09fMVlPUkVPLXh6MUExZ1hpaEEAFjBGbmVEZHdGU1EtaFhhUFc4ZkR5cWcAAAAAAAAAAAIWaXBPNVJtZEhTZDZXTWFFR05waXdWZwEWSEY3T18xWU9SRU8teHoxQTFnWGloQQAA"
]
}
```
#### Sample response
```json
index shard prirep ip segment generation docs.count docs.deleted size size.memory committed searchable version compound
index1 0 r 10.212.36.190 _0 0 4 0 3.8kb 1364 false true 8.8.2 true
index1 1 p 10.212.36.190 _0 0 3 0 3.7kb 1364 false true 8.8.2 true
index1 2 r 10.212.74.139 _0 0 2 0 3.6kb 1364 false true 8.8.2 true
```
## PIT settings
You can specify the following settings for a PIT.
Setting | Description | Default
:--- | :--- | :---
point_in_time.max_keep_alive | A cluster-level setting that specifies the maximum value for the `keep_alive` parameter. | 24h
search.max_open_pit_context | A node-level setting that specifies the maximum number of open PIT contexts for the node. | 300

154
_opensearch/point-in-time.md Normal file
View File

@ -0,0 +1,154 @@
---
layout: default
title: Point in Time
nav_order: 58
has_children: true
has_toc: false
---
# Point in Time
Point in Time (PIT) lets you run different queries against a dataset that is fixed in time.
Normally, if you run a query on an index multiple times, the same query may return different results because documents are continually indexed, updated, and deleted. If you need to run a query against the same data, you can preserve that data's state by creating a PIT. The main use of the PIT feature is to couple it with the `search_after` functionality for deep pagination of search results.
## Paginating search results
Besides the PIT functionality, there are three ways to [paginate search results]({{site.url}}{{site.baseurl}}/opensearch/search/paginate) in OpenSearch: using the Scroll API, specifying `from` and `size` parameters for your search, and using the `search_after` functionality. However, all three have limitations:
- The Scroll API's search results are frozen at the moment of the request, but they are bound to a particular query. Additionally, scroll can only move forward in the search, so if a request for a page fails, the subsequent request skips that page and returns the following one.
- If you specify the `from` and `size` parameters for your search, the search results are not frozen in time, so they may be inconsistent because of documents being indexed or deleted. The `from` and `size` feature is not recommended for deep pagination because every page request requires processing of all results and filtering them for the requested page.
- The `search_after` search results are not frozen in time, so they may be inconsistent because of concurrent document indexing or deletion.
The PIT functionality does not have the limitations of other pagination methods, because PIT search is not bound to a query, and it supports consistent pagination going forward and backward. If you have looked at page one of your results and are now on page two, you will see the same page one if you go back.
## PIT search
PIT search has the same capabilities as regular search, except PIT search acts on an older dataset, while a regular search acts on a live dataset. PIT search is not bound to a query, so you can run different queries on the same dataset, which is frozen in time.
You can use the [Create PIT API]({{site.url}}{{site.baseurl}}/opensearch/point-in-time) to create a PIT. When you create a PIT for a set of indexes, OpenSearch locks a set of segments for those indexes, freezing them in time. On a lower level, none of the resources required for this PIT are modified or deleted. If the segments that are part of a PIT are merged, OpenSearch retains a copy of those segments for the period of time specified at PIT creation by the `keep_alive` parameter.
The create PIT operation returns a PIT ID, which you can use to run multiple queries on the frozen dataset. Even though the indexes continue to ingest data and modify or delete documents, the PIT references the data that has not changed since the PIT creation. When your query contains a PIT ID, you don't need to pass the indexes to the search because it will use that PIT. A search with a PIT ID will produce exactly the same result when you run it multiple times.
## Pagination with PIT and search_after
When you run a query with a PIT ID, you can use the `search_after` parameter to retrieve the next page of results. This gives you control over the order of documents in the pages of results.
Run a search query with a PIT ID:
```json
GET /_search
{
"size": 10000,
"query": {
"match" : {
"user.id" : "elkbee"
}
},
"pit": {
"id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA==",
"keep_alive": "100m"
},
"sort": [
{"@timestamp": {"order": "asc", "format": "strict_date_optional_time_nanos"}},
{"_shard_doc": "desc"}
]
}
```
The response contains the first 10,000 documents that match the query. To get the next set of documents, run the same query with the last document's sort values as the `search_after` parameter, keeping the same `sort` and `pit.id`. You can use the optional `keep_alive` parameter to extend the PIT time:
```json
GET /_search
{
"size": 10000,
"query": {
"match" : {
"user.id" : "elkbee"
}
},
"pit": {
"id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA==",
"keep_alive": "100m"
},
"sort": [
{"@timestamp": {"order": "asc", "format": "strict_date_optional_time_nanos"}},
{"_shard_doc": "desc"}
],
"search_after": [
"2021-05-20T05:30:04.832Z"
]
}
```
## Search slicing
Using `search_after` with PIT for pagination gives you control over ordering of the results. If you don't need results in any specific order, or if you want the ability to jump from a page to a non-consecutive page, you can use search slicing. Search slicing splits a PIT search into multiple slices that can be consumed independently by a client application.
For example, if you have a PIT search query that has 1,000,000 results and you want to return 50,000 results at a time, your client application has to make 20 consecutive calls to receive each batch of results. If you use search slicing, you can parallelize these 20 calls. In your multithreaded client application you can use five slices for each PIT. As a result, you will have 5 10,000-hit slices that can be consumed by five different threads in your client, instead of having a single thread consume 50,000 results.
To use search slicing, you have to specify two parameters:
- `slice.id` is the slice ID you are requesting.
- `slice.max` is the number of slices to break the search response into.
The following PIT search query illustrates search slicing:
```json
GET /_search
{
"slice": {
"id": 0, // id is the slice (page) number being requested. In every request we can only query for one slice
"max": 2 // max is the total number of slices (pages) the search response will be broken down into
},
"query": {
"match": {
"message": "foo"
}
},
"pit": {
"id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA=="
}
}
```
In every request you can only query for one slice, so the next query will be the same as the previous one, except the `slice.id` will be `1`.
## Security model
This section describes the permissions needed to use PIT API operations if you are running OpenSearch with the security plugin enabled.
Users can access all PIT API operations using the `point_in_time_full_access` role. If this role doesn't meet your needs, mix and match individual PIT permissions to suit your use case. Each action corresponds to an operation in the REST API. For example, the `indices:data/read/point_in_time/create` permission lets you create a PIT. The following are the possible permissions:
- `indices:data/read/point_in_time/create` &ndash; Create API
- `indices:data/read/point_in_time/delete` &ndash; Delete API
- `indices:data/read/point_in_time/readall` &ndash; List All PITs API
- `indices:data/read/search` &ndash; Search API
- `indices:monitor/point_in_time/segments` &ndash; PIT Segments API
For `all` API operations, such as list all and delete all, the user needs the all indexes (*) permission. For API operations such as search, create PIT, or delete list, the user only needs individual index permissions.
The PIT IDs always contain the underlying (resolved) indexes when saved. The following sections describe the required permissions for aliases and data streams.
### Alias permissions
For aliases, users must have either index **or** alias permissions for any PIT operation.
### Data stream permissions
For data streams, users must have both the data stream **and** the data stream's backing index permissions for any PIT operation. For example, the user must have permissions for the `data-stream-11` data stream and for its backing index `.ds-my-data-stream11-000001`.
If users have the data stream permissions only, they will be able to create a PIT, but they will not be able to use the PIT ID for other operations, such as search, without the backing index permissions.
## API
The following table lists all [Point in Time API]({{site.url}}{{site.baseurl}}/opensearch/point-in-time-api) functions.
Function | API | Description
:--- | :--- | :---
[Create PIT]({{site.url}}{{site.baseurl}}/opensearch/point-in-time-api#create-a-pit) | `POST /<target_indexes>/_search/point_in_time?keep_alive=1h` | Creates a PIT.
[List PIT]({{site.url}}{{site.baseurl}}/opensearch/point-in-time-api#list-all-pits) | `GET /_search/point_in_time/_all` | Lists all PITs.
[Delete PIT]({{site.url}}{{site.baseurl}}/opensearch/point-in-time-api#delete-pits) | `DELETE /_search/point_in_time`<br> `DELETE /_search/point_in_time/_all` | Deletes a PIT or all PITs.
[PIT segments]({{site.url}}{{site.baseurl}}/opensearch/point-in-time-api#pit-segments) | `GET /_cat/pit_segments/_all` | Provides information about the disk utilization of a PIT by describing its Lucene segments.
For information about the relevant cluster and node settings, see [PIT Settings]({{site.url}}{{site.baseurl}}/opensearch/point-in-time-api#pit-settings)

3
_security-plugin/access-control/users-roles.md
View File

@ -125,9 +125,10 @@ Role | Description
`reports_full_access` | Grants full permissions to reports.
`asynchronous_search_full_access` | Grants full permissions to all asynchronous search actions.
`asynchronous_search_read_access` | Grants permissions to view asynchronous searches but not to submit, modify, or delete async searches.
`index_management_full_access` | Grants full permissions to all index management actions, including ISM, transforms, and rollups.
`index_management_full_access` | Grants full permissions to all index management actions, including Index State Management (ISM), transforms, and rollups.
`snapshot_management_full_access` | Grants full permissions to all snapshot management actions.
`snapshot_management_read_access` | Grants permissions to view policies but not create, modify, start, stop, or delete them.
`point_in_time_full_access` | Grants full permissions to all Point in Time operations.
For more detailed summaries of the permissions for each role, reference their action groups against the descriptions in [Default action groups]({{site.url}}{{site.baseurl}}/security-plugin/access-control/default-action-groups/).