Search after for efficient pagination in Elasticsearch - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of search_after with sort keys

What will be the output of the following Elasticsearch query snippet when using search_after for pagination?

Assume the index contains documents sorted by timestamp ascending and id ascending.

{
  "size": 2,
  "query": { "match_all": {} },
  "sort": [
    { "timestamp": "asc" },
    { "id": "asc" }
  ],
  "search_after": ["2023-01-01T00:00:00", "100"]
}

Given the documents:

• {"timestamp": "2023-01-01T00:00:00", "id": "100"}
• {"timestamp": "2023-01-01T00:00:01", "id": "101"}
• {"timestamp": "2023-01-01T00:00:02", "id": "102"}

Which documents will be returned?

Elasticsearch

{
  "size": 2,
  "query": { "match_all": {} },
  "sort": [
    { "timestamp": "asc" },
    { "id": "asc" }
  ],
  "search_after": ["2023-01-01T00:00:00", "100"]
}

A Documents with timestamp "2023-01-01T00:00:01" and id "101", and timestamp "2023-01-01T00:00:02" and id "102"

B Documents with timestamp "2023-01-01T00:00:00" and id "100" only

C Documents with timestamp "2023-01-01T00:00:00" and id "100", and timestamp "2023-01-01T00:00:01" and id "101"

D No documents returned

💡 Hint

Remember that search_after returns documents after the given sort values, excluding the document with those exact values.

The search_after parameter returns documents strictly after the given sort values. Since the sort is by timestamp ascending and then id ascending, documents with timestamp "2023-01-01T00:00:00" and id "100" are excluded. The next documents are those with timestamp "2023-01-01T00:00:01" and id "101", and then "2023-01-01T00:00:02" and id "102".

🧠 Conceptual

intermediate

Why use search_after instead of from/size for deep pagination?

Why is search_after recommended over from and size for deep pagination in Elasticsearch?

A Because from/size does not support sorting, while search_after does.

B Because search_after automatically caches all previous pages for faster access.

C Because search_after uses the last sort values to efficiently continue from the previous page, avoiding performance issues.

D Because search_after returns documents in random order, which is faster.

💡 Hint

Think about how Elasticsearch handles skipping documents with from/size.

Using from/size for deep pagination requires Elasticsearch to skip many documents, which is slow and resource-intensive. search_after uses the last document's sort values to continue efficiently without skipping.

🔧 Debug

advanced

Identify the error in search_after usage

What error will this Elasticsearch query produce?

{
  "size": 3,
  "query": { "match_all": {} },
  "sort": [
    { "date": "desc" }
  ],
  "search_after": ["2023-05-01"]
}

Assuming the date field is of type date and the sort expects a date and a tie-breaker field.

Elasticsearch

{
  "size": 3,
  "query": { "match_all": {} },
  "sort": [
    { "date": "desc" }
  ],
  "search_after": ["2023-05-01"]
}

A The query will run successfully and return documents after the given date.

B Elasticsearch will raise a SearchPhaseExecutionException due to missing tie-breaker sort field.

C Elasticsearch will raise a ParsingException due to invalid date format in search_after.

D The query will return documents sorted ascending instead of descending.

💡 Hint

search_after requires the sort fields and search_after values to match exactly in number and order.

When using search_after, the sort array must include a tie-breaker field (like _id) to ensure unique sorting. The search_after array must have the same number of values as the sort fields. Missing the tie-breaker causes an error.

📝 Syntax

advanced

Correct search_after syntax for multi-field sort

Which of the following is the correct search_after syntax for this sort?

"sort": [
  { "price": "asc" },
  { "rating": "desc" },
  { "_id": "asc" }
]

A [100, 4.5, "abc123"]

B [100, "abc123", 4.5]

C ["abc123", 100, 4.5]

D [4.5, 100, "abc123"]

💡 Hint

The order of values in search_after must match the order of fields in sort.

The search_after array must have values in the same order as the sort fields: price (asc), rating (desc), then _id (asc). So the values are [price_value, rating_value, _id_value].

🚀 Application

expert

Implementing efficient deep pagination with search_after

You have an Elasticsearch index with millions of documents sorted by created_at ascending and doc_id ascending.

You want to fetch page 1000 with 10 documents per page efficiently.

Which approach correctly uses search_after to get page 1000?

A Use a scroll API instead of search_after for page 1000.

B Use from: 9990 and size: 10 to jump directly to page 1000.

C Use search_after with the sort values from page 1 to jump directly to page 1000.

D Iteratively query pages 1 to 999 using search_after, storing the last sort values each time, then query page 1000 with those values.

💡 Hint

search_after requires the last document's sort values from the previous page to continue.

search_after requires the last document's sort values from the previous page to fetch the next page. To get page 1000, you must iterate through pages 1 to 999, saving the last sort values each time, then use those values to query page 1000.