Introduce point in time APIs in x-pack basic

[dnhatn]

This commit introduces a new API that manages point-in-times in x-pack basic. Elasticsearch pit (point in time) is a lightweight view into the state of the data as it existed when initiated. A search request by default executes against the most recent point in time. In some cases, it is preferred to perform multiple search requests using the same point in time. For example, if refreshes happen between search_after requests, then the results of those requests might not be consistent as changes happening between searches are only visible to the more recent point in time.

A point in time must be opened before being used in search requests. The keep_alive parameter tells Elasticsearch how long it should keep a point in time around.

POST /my_index/_pit?keep_alive=1m

The response from the above request includes a id, which should be passed to the id of the pit parameter of search requests.

POST /_search
{
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    },
    "pit": {
	    "id":  "46ToAwMDaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQNpZHkFdXVpZDIrBm5vZGVfMwAAAAAAAAAAKgFjA2lkeQV1dWlkMioGbm9kZV8yAAAAAAAAAAAMAWICBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA==",
	    "keep_alive": "1m"
    }
}

Point-in-times are automatically closed when the keep_alive is elapsed. However, keeping point-in-times has a cost; hence, point-in-times should be closed as soon as they are no longer used in search requests.

DELETE /_pit
{
    "id" : "46ToAwMDaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQNpZHkFdXVpZDIrBm5vZGVfMwAAAAAAAAAAKgFjA2lkeQV1dWlkMioGbm9kZV8yAAAAAAAAAAAMAWIBBXV1aWQyAAA="
}

Notable works in this change:

• Move the search state to the coordinating node: Move states of search to coordinating node #52741
• Allow searches with a specific reader context: Allow searches with specific reader contexts #53989
• Add the ability to acquire readers in IndexShard: Adds the ability to acquire readers in IndexShard #54966

Relates #46523
Relates #26472

Co-authored-by: Jim Ferenczi <[email protected]>

[elasticmachine]

Pinging @elastic/es-search (:Search/Search)

[dnhatn]

@albertzaharovits @jimczi Thank you for the discussion today. I've pushed:

• 8a7eb6a to override the indices of a search request using the resolved indices from the point in time parameter.
• fa4b4c6 to restore the current behavior of SecuritySearchOperationListener.

[jimczi]

LGTM, although we don't handle aliases that have different permissions that their backing indices. We discussed with @albertzaharovits and the @elastic/es-security and agreed that we'll throw an error if we detect an alias with different security during the creation of the PIT. That doesn't mean that we'll never fix this on PIT but we prefer to consider it as a feature since the future of aliases in Security is not settled yet (we may remove this functionality in 8).

[Rupesh282]

Hi @dnhatn, I want to do deep pagination using a query & sort on a couple of indices in my es cluster.
I am trying to see if search_after has any advantage over scroll in this case. As I need stateful data, using PIT (Point in Time) with search_after.
Things I have found so far through code :

• There is no major difference between context stored of PIT (point in time) method & context of scroll. Just that scroll context has some more information about incoming request.
  Class reference :-
  • org.elasticsearch.search.internal.LegacyReaderContext
  • org.elasticsearch.search.internal.ReaderContext
• Both scroll & search_after utilise sorting to hold minimal data (O(size)) at each shard's priority queue.

I want to do deep pagination in which from+size can go beyond 100k. ( though size will always be 5k, only from is increasing ).

Your opinion on this will be appreciated, Thanks !