Runtime Fields — 매핑을 미리 안 정해도 되는 쿼리 시점 계산 필드
Elasticsearch Runtime Fields 및 Synonym 필터 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(manage-data/data-store/mapping/runtime-fields, reference/text-analysis/analysis-synonym-graph-tokenfilter) Elastic 공식 문서 Runtime fields
이 모듈을 다 읽으면
- runtime field가 색인 시점이 아니라 쿼리 시점에 계산된다는 것을 설명할 수 있다
- 이 유연성이 어떤 성능 대가를 요구하는지, 어떤 상황에 적합한지 설명할 수 있다
elasticsearch-learn-03에서 다룬 매핑(색인 시점에 필드 타입을 미리 정의하는 것)과 대비되는, 필드 값을 색인해두지 않고 매 쿼리 실행 시점에 Painless 스크립트로 즉석 계산하는 runtime field를 정리한다.
쿼리 시점 계산 — 색인은 그대로, 스크립트가 매 쿼리마다 값을 만든다
runtime field는 색인 시점에 미리 계산돼 디스크에 저장되는 일반 필드와 달리, 쿼리가 매칭한 문서들에 대해 매번 Painless 스크립트를 실행해 그 자리에서 값을 계산한다. 이 방식 덕분에 기존 문서를 재색인(reindex)하지 않고도 새로운 필드를 추가해 곧바로 검색·집계·필터에 쓸 수 있고, 매핑을 미리 확정하지 않아도 되므로 저장 공간도 늘지 않는다(색인 크기 자체가 커지지 않음).
핵심 포인트
- runtime field는 색인 시점이 아니라 쿼리 시점에 Painless 스크립트로 값을 즉석 계산
- 재색인 없이 기존 문서에 새 필드를 추가해 곧바로 검색/집계/필터에 사용 가능, 색인 크기도 늘지 않음
대가 — 유연성과 맞바꾸는 쿼리 성능
runtime field는 디스크 공간을 덜 쓰고 데이터 접근 방식에 유연성을 주지만, 스크립트에 정의된 계산 복잡도에 따라 검색 성능에 영향을 줄 수 있다 — runtime field를 대상으로 하는 쿼리는 '비용이 큰(expensive)' 연산으로 취급된다. 즉 '색인 시점에 미리 계산해두고 저장 vs 쿼리 시점에 매번 계산' 사이의 전형적인 트레이드오프이며, 자주 반복 조회되는 안정적인 필드라면 결국 정식 매핑 필드로 재색인하는 게 유리할 수 있다.
핵심 포인트
- runtime field 쿼리는 스크립트 계산 복잡도에 따라 검색 성능에 영향 — '비용이 큰' 연산으로 취급됨
- 자주 반복 조회되는 안정적인 필드라면 결국 정식 매핑 필드로 재색인하는 것이 유리할 수 있음
전형적 용도 — 탐색적 분석과 과거 데이터에 필드 추가
로그 데이터처럼 아직 구조를 확신할 수 없는 데이터를 다룰 때, 매핑 스키마를 미리 확정하지 않고 runtime field로 우선 탐색·분석을 시작한 뒤 나중에 구조를 다듬을 수 있다. 또한 이미 색인된 과거 데이터에 새로운 파생 필드를 추가하고 싶을 때, 대규모 데이터셋 전체를 재색인하는 운영 부담 없이 runtime field로 즉시 적용해볼 수 있다는 것도 실무적으로 자주 쓰이는 이유다.
핵심 포인트
- 구조를 아직 확신할 수 없는 로그 데이터 등을 매핑 확정 전에 탐색적으로 분석할 때 적합
- 과거에 이미 색인된 대규모 데이터에 새 파생 필드를 재색인 부담 없이 즉시 추가하고 싶을 때 적합