term vs match 쿼리 — '분석하지 않는다'는 게 핵심이다
Elasticsearch term/match 쿼리 구분 및 Composite Aggregation 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(query-dsl-term-query, search-aggregations-bucket-composite-aggregation) Elastic 공식문서 Term query
이 모듈을 다 읽으면
- term 쿼리가 elasticsearch-learn-03의 analyzer 파이프라인을 아예 거치지 않는다는 것을 설명할 수 있다
- text 필드에 term 쿼리를 쓰면 왜 예상과 다른 결과가 나오는지 설명할 수 있다
elasticsearch-learn-03에서 다룬 매핑·analyzer 파이프라인(색인 시점에 텍스트를 토큰으로 쪼개는 과정)을 전제로, 검색 시점의 term 쿼리와 match 쿼리가 이 파이프라인을 각각 어떻게 다르게 취급하는지를 정리한다.
핵심 차이 — match는 분석하고, term은 분석하지 않는다
match 쿼리는 elasticsearch-learn-03에서 다룬 필드 매핑을 이해한다 — 입력된 검색어를 그 필드에 지정된 analyzer로 똑같이 분석(토큰화)한 뒤, 그 토큰들로 역인덱스를 검색한다. term 쿼리는 이와 정반대다 — 매핑 타입을 전혀 고려하지 않고, 입력값을 있는 그대로 역인덱스에서 찾는다. 즉 term은 '이 값 그대로가 역인덱스 안의 term과 정확히 일치하는가'만 보고, match는 '내가 검색어를 넣으면 필드가 색인될 때와 같은 방식으로 분석해서 찾아주는가'를 본다.
핵심 포인트
- match 쿼리: 검색어를 그 필드의 analyzer로 분석(토큰화)한 뒤 검색 — 필드 매핑을 이해함
- term 쿼리: 매핑 타입을 전혀 고려하지 않고 입력값을 그대로 역인덱스에서 찾음 — analyzer 파이프라인 자체를 거치지 않음
함정 — text 필드에 term 쿼리를 쓰면 안 되는 이유
공식 문서는 text 필드에 term 쿼리를 쓰지 말라고 명시적으로 경고한다 — text 필드는 기본적으로 색인 시점에 analyzer를 거쳐 원래 값이 소문자화·토큰화 등으로 바뀌어(예: 'Quick Fox'가 'quick'과 'fox' 두 토큰으로) 저장되기 때문이다. term 쿼리로 원본 문자열 'Quick Fox'를 그대로 찾으려 하면, 역인덱스 안에는 애초에 그 형태로 저장된 게 없어 매칭이 안 된다. 정확한 값 검색(가격, 상품 ID, 사용자명처럼 분석되지 않는 값)에는 term을, 자유 텍스트 검색에는 match를 쓰는 게 원칙이다 — 성능 면에서는 term이 역인덱스를 바로 조회해 일반적으로 더 빠르다.
핵심 포인트
- text 필드는 색인 시점에 이미 analyzer를 거쳐 원본과 다른 형태로 저장됨 — term 쿼리로 원본 그대로 찾으면 매칭 안 됨(공식 경고)
- 원칙: 정확값 검색(가격·ID·사용자명 등 분석 안 되는 값)엔 term, 자유 텍스트 검색엔 match — term이 역인덱스 직접 조회라 일반적으로 더 빠름