Point in Time(PIT) API — search_after만으로는 부족한 이유
Elasticsearch Point in Time API 및 샤드 할당 필터링 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(api/doc/elasticsearch/operation/operation-open-point-in-time, reference/elasticsearch/index-settings/shard-allocation) Elastic 공식 문서 Open a point in time
이 모듈을 다 읽으면
- search_after 단독으로는 페이지 사이에 인덱스가 바뀌는 문제를 못 막는 이유를 설명할 수 있다
- PIT를 열고 search_after와 함께 쓰는 흐름과 keep_alive의 역할을 설명할 수 있다
elasticsearch-learn-24에서 다룬 search_after(커서 기반 페이지네이션)를 전제로, 그 커서 방식만으로는 페이지를 넘기는 사이 인덱스에 새 문서가 들어오거나 지워지면 결과가 일관되지 않을 수 있다는 한계를 보완하는 Point in Time(PIT) API를 정리한다.
문제 — search_after만으로는 '스냅샷'이 보장 안 된다
elasticsearch-learn-24에서 다룬 search_after는 이전 페이지의 정렬 값을 커서처럼 넘겨 다음 페이지를 이어가는 방식이지만, 그 자체로는 인덱스가 요청 사이에 계속 살아 움직이는 것까지 막아주지는 않는다 — 페이지를 넘기는 도중에 새 문서가 추가되거나 기존 문서가 삭제·수정되면, 페이지 간에 결과가 중복되거나 누락되는 일이 생길 수 있다. PIT는 이 문제를 풀기 위해 '검색이 시작된 순간의 인덱스 상태'를 가벼운 뷰로 고정해두는 기능이다.
핵심 포인트
- search_after 단독으로는 페이지를 넘기는 도중 인덱스가 바뀌면(추가/삭제/수정) 결과 일관성이 깨질 수 있음
- PIT는 '검색이 시작된 순간의 인덱스 상태'를 가벼운 뷰로 고정해 이 문제를 해결
pit_id를 search_after와 함께 넘긴다
PIT를 열면 응답으로 id(흔히 pit_id로 부름)라는 불투명한 문자열을 받는데, 이를 이후 검색 요청에 실어 보내야 한다 — 중요한 점은 open 요청이나 각 검색 요청이 반환하는 id가 매번 달라질 수 있으므로, 항상 '가장 최근에 받은 ID'를 다음 검색에 써야 한다는 것이다. PIT를 쓰는 검색 요청에는 index, routing, preference 값을 따로 지정하면 안 되는데, 이 값들은 이미 PIT 자체에서 가져오기 때문이다. 더 많은 결과를 계속 가져오고 싶으면 이 PIT를 search_after와 함께 쓰는 것이 표준 패턴이다.
핵심 포인트
- PIT open 응답의 id(pit_id)를 이후 검색 요청에 실어 보내되, 매번 가장 최근에 받은 ID를 써야 함(요청마다 바뀔 수 있음)
- PIT를 쓰는 요청은 index/routing/preference를 별도 지정 불가(PIT에서 이미 가져옴) — 더 가져오려면 PIT+search_after 조합이 표준
keep_alive — PIT가 리소스를 얼마나 붙들고 있을지
keep_alive 파라미터는 PIT open 요청과 이후 검색 요청 양쪽에 지정할 수 있으며, 그 PIT의 생존 시간(TTL)을 연장하는 역할을 한다 — 즉 PIT를 계속 쓰려면 검색을 이어갈 때마다 keep_alive를 함께 보내 만료 시점을 뒤로 미뤄야 한다. PIT는 그 순간의 데이터 상태를 유지하기 위해 관련 세그먼트 파일들이 삭제되지 않도록 붙들고 있으므로, 다 쓴 PIT는 명시적으로 닫아 자원을 반납하는 것이 좋은 관행이다.
핵심 포인트
- keep_alive는 open 요청과 각 검색 요청 양쪽에 지정 가능 — PIT의 TTL을 연장하는 역할, 계속 쓰려면 매 요청마다 갱신 필요
- PIT는 그 순간 상태 유지를 위해 세그먼트 파일을 붙들고 있으므로, 다 쓴 PIT는 명시적으로 닫아 자원 반납하는 게 좋은 관행