Completion Suggester — 역인덱스 대신 FST로 만드는 즉각 반응 자동완성
Elasticsearch Completion Suggester 및 search_after 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(reference/elasticsearch/rest-apis/search-suggesters, reference/elasticsearch/rest-apis/paginate-search-results) Elastic 공식 문서 Search suggesters — Completion suggester
이 모듈을 다 읽으면
- Completion Suggester가 역인덱스 대신 FST라는 별도 자료구조를 쓰는 이유를 설명할 수 있다
- input/weight 구조가 자동완성 결과 랭킹에 어떻게 쓰이는지 설명할 수 있다
elasticsearch-learn-02에서 다룬 역인덱스 기반 검색과 근본적으로 다른 방식으로 동작하는, 사용자가 한 글자씩 입력할 때마다 즉각 반응해야 하는 자동완성(type-ahead) 전용 기능인 Completion Suggester를 정리한다.
왜 역인덱스로는 부족한가 — FST라는 별도 자료구조
일반 text 필드에 prefix 쿼리를 쓰는 방식은 결국 역인덱스를 순회하는 것이라, 디스크 I/O와 인덱스 탐색 오버헤드 때문에 자동완성처럼 사용자가 한 글자씩 입력할 때마다 즉시 반응해야 하는 대량 요청 상황에서는 느리다. Completion Suggester는 이 문제를 애초에 다른 자료구조로 우회한다 — 색인 시점에 FST(finite state transducer)라는, 빠른 조회에 최적화된 자료구조를 미리 만들어 완전히 메모리에 올려둔다. 공식 문서도 이 자료구조가 '조회는 빠르지만 만드는 데는 비용이 크고 인메모리에 저장된다'고 명시해, 색인 시점의 빌드 비용을 감수하고 조회 속도를 극대화하는 트레이드오프임을 밝힌다.
핵심 포인트
- 일반 text 필드의 prefix 쿼리는 역인덱스 순회라 디스크 I/O·탐색 오버헤드로 자동완성 규모의 요청 빈도에는 느림
- Completion Suggester는 색인 시점에 FST를 만들어 완전히 메모리에 올려둠 — 빌드 비용은 크지만 조회는 매우 빠른 트레이드오프
input/weight — 여러 표현을 하나의 항목에 묶고 가중치로 순위를 매긴다
제안 데이터는 input(매칭 대상 문자열, 문자열 하나 또는 배열 가능)과 weight(순위를 결정하는 선택적 양의 정수) 두 요소로 색인된다 — 예를 들어 {"input": ["Nevermind", "Nirvana"], "weight": 34}처럼 하나의 결과 항목에 여러 개의 매칭 가능한 표현(앨범명과 아티스트명 등)을 함께 묶어두고, 조회 시점에는 입력된 접두사와 이 input들을 매칭한 뒤 weight 기준으로 순위를 매겨 반환한다.
핵심 포인트
- input(매칭 대상 문자열, 배열 가능)과 weight(순위 결정용 양의 정수) 두 요소로 제안 데이터를 색인
- 하나의 결과 항목에 여러 표현(예: 앨범명+아티스트명)을 input 배열로 함께 묶어두고 weight로 순위 결정
실무 고려사항 — 근실시간 가시성, 메모리 상주, 샤드 수
FST가 메모리에 상주하는 구조이다 보니 대규모 제안 데이터셋에서는 힙 메모리 사용량을 모니터링하는 게 중요하다. 또한 다른 Elasticsearch 데이터와 마찬가지로 색인 직후 즉시 보이는 게 아니라 refresh가 일어나야 검색에 반영되는 근실시간(near real-time) 특성을 갖는다. 성능 면에서는 단일 샤드 인덱스에서 최적의 성능이 나오고, 여러 샤드에 걸친 completion은 문서를 추가로 가져오는(fetch) 오버헤드가 발생한다는 점도 설계 시 고려해야 한다.
핵심 포인트
- FST가 힙 메모리에 상주 — 대규모 제안 데이터셋에서는 메모리 모니터링이 중요
- 색인 직후 즉시 반영 아닌 근실시간 특성, 단일 샤드에서 최적 성능(다중 샤드는 문서 fetch 오버헤드 발생)