Point-in-time API in Elasticsearch - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the Point-in-time (PIT) API in Elasticsearch?

The Point-in-time API lets you create a snapshot of your data at a specific moment. This snapshot helps you search data consistently, even if the data changes later.

intermediate

Why use Point-in-time API instead of scroll API?

PIT is simpler and more efficient for deep pagination. It keeps a consistent view without locking resources for a long time, unlike scroll which holds resources and can be slower.

beginner

How do you create a point-in-time in Elasticsearch?

You send a POST request to the endpoint /_search?scroll=1m&pit= with the index name or use /_search with pit parameter. Elasticsearch returns a pit_id which you use in your search requests.

intermediate

What must you do after finishing searches with a point-in-time?

You should delete the point-in-time using the DELETE /_pit API with the pit_id. This frees up resources on the server.

beginner

How does Point-in-time API help with consistent pagination?

PIT keeps the data snapshot fixed, so when you request pages of results, you see the same data even if new documents are added or deleted during pagination.

What does the Point-in-time API provide in Elasticsearch?

A A tool to monitor cluster health

B A way to update documents in bulk

C A method to delete indices

D A consistent snapshot of data for searching

The Point-in-time API provides a consistent snapshot of data for searching, ensuring stable results during pagination.

Which HTTP method is used to create a point-in-time?

A POST

B DELETE

C PUT

D GET

You use POST to create a point-in-time snapshot in Elasticsearch.

What do you receive after creating a point-in-time?

A An index name

B A scroll_id

C A pit_id

D A cluster status

Elasticsearch returns a pit_id to identify the point-in-time snapshot.

Why should you delete a point-in-time after use?

A To free server resources

B To refresh the index

C To update the snapshot

D To improve search speed

Deleting the point-in-time frees server resources that were reserved for the snapshot.

Which API is better for deep pagination with consistent data?

A Scroll API

B Point-in-time API

C Update API

D Delete API

The Point-in-time API is better for deep pagination because it provides a consistent view without locking resources.

Explain how the Point-in-time API helps maintain consistent search results during pagination.

Think about how data changes and how PIT keeps it stable.

Describe the steps to use the Point-in-time API from creation to cleanup.

Consider the lifecycle of a PIT snapshot.

Practice

1.

What is the main purpose of the Point-in-time (PIT) API in Elasticsearch?

easy

A. To provide a consistent snapshot of data for searches

B. To delete old indices automatically

C. To update documents in bulk

D. To monitor cluster health status

Solution

1. Step 1: Identify PIT API's main purpose

   The PIT API creates a stable snapshot of the data at a point in time for consistent searches even if data changes; deleting indices (A), bulk updates (C), and monitoring health (D) are unrelated.

2. Final Answer:

   To provide a consistent snapshot of data for searches -> Option A

3. Quick Check:

   PIT API = consistent snapshot [OK]

Hint: PIT API = stable snapshot for consistent search results [OK]

Common Mistakes:

• Confusing PIT with index deletion
• Thinking PIT updates documents
• Assuming PIT monitors cluster health

2.

Which of the following is the correct way to open a point-in-time in Elasticsearch using the REST API?

{
  "keep_alive": "1m"
}

easy

A. POST /_search/point_in_time/create
{ "keep_alive": "1m" }

B. POST /_search/point_in_time/open
{ "keep_alive": "1m" }

C. POST /_search/point_in_time/_open
{ "keep_alive": "1m" }

D. POST /_search/point_in_time
{ "keep_alive": "1m" }

Solution

1. Step 1: Identify correct PIT open endpoint

   POST /_search/point_in_time/_open with keep_alive "1m" is correct; /open, /create, or missing _open are invalid.

2. Final Answer:

   POST /_search/point_in_time/_open { "keep_alive": "1m" } -> Option C

3. Quick Check:

   Correct PIT open endpoint = /_search/point_in_time/_open [OK]

Hint: PIT open uses _open endpoint with keep_alive [OK]

Common Mistakes:

• Missing underscore before 'open'
• Using wrong endpoint like /create
• Confusing PIT open with search endpoint

3.

Given the following Elasticsearch query using a point-in-time ID, what will be the value of pit_id in the search response?

POST /my-index/_search
{
  "pit": {
    "id": "abc123",
    "keep_alive": "2m"
  },
  "query": { "match_all": {} },
  "size": 1
}

medium

A. A new PIT ID string

B. "2m"

C. "abc123"

D. null

Solution

1. Step 1: Analyze PIT ID in search response

   Searching with input PIT ID "abc123" and keep_alive "2m" returns a new PIT ID string for paging, not the input ID, "2m", or null.

2. Final Answer:

   A new PIT ID string -> Option A

3. Quick Check:

   Search with PIT returns new PIT ID [OK]

Hint: Search with PIT returns updated PIT ID for paging [OK]

Common Mistakes:

• Expecting same PIT ID returned
• Confusing keep_alive value as PIT ID
• Assuming PIT ID is null in response

4.

Identify the error in this Elasticsearch request to use a point-in-time for paging:

POST /my-index/_search
{
  "pit": {
    "id": "",
    "keep_alive": "1m"
  },
  "query": { "match_all": {} },
  "size": 10
}

medium

A. The keep_alive value should be a number, not a string

B. The PIT ID is empty, which is invalid

C. The query must include a sort field when using PIT

D. The size parameter cannot be 10 when using PIT

Solution

1. Step 1: Identify the error in PIT request

   Empty PIT ID "" is invalid and causes error; keep_alive "1m" string is correct, size 10 allowed, sort optional.

2. Final Answer:

   The PIT ID is empty, which is invalid -> Option B

3. Quick Check:

   Empty PIT ID causes error [OK]

Hint: PIT ID must be non-empty string [OK]

Common Mistakes:

• Leaving PIT ID empty
• Misunderstanding keep_alive format
• Thinking size must be fixed when using PIT

5.

You want to page through a large dataset using the Point-in-time API. Which sequence of steps correctly uses PIT to avoid missing or repeating documents?

hard

A. Use PIT ID only once, then open a new PIT for each page

B. Search without PIT, use scroll API for paging, close scroll after done

C. Open PIT without keep_alive, search once, then close PIT immediately

D. Open PIT with keep_alive, search with PIT ID, use returned PIT ID for next search, repeat until no hits

Solution

1. Step 1: Outline correct PIT paging sequence

   Open PIT with keep_alive, search using PIT ID (update to new returned PIT ID each time), repeat until no hits, then close; avoids new PITs per page (A), scroll (B), or no paging (C).

2. Final Answer:

   Open PIT with keep_alive, search with PIT ID, use returned PIT ID for next search, repeat until no hits -> Option D

3. Quick Check:

   Proper PIT paging = open, search, update PIT ID, repeat [OK]

Hint: Open PIT once, use updated PIT IDs to page [OK]

Common Mistakes:

• Using scroll API instead of PIT for paging
• Not updating PIT ID after each search
• Opening new PIT for every page