저장 공간과 검색 기능, 계산 비용을 비교해 두 OpenSearch 필드 기능을 필요한 곳에만 적용하는 방법을 정리합니다. 여러 선택지를 한 번에 적용하기보다 ‘match_only_text’부터 확인합니다. 문서의 존재 여부 중심 검색에 맞춘 텍스트 필드입니다. 위치 정보가 필요한 구문·근접 검색이나 복잡한 점수 계산 요구가 있는지 먼저 확인합니다.
이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.
처음 확인할 경계
match_only_text는 저장과 검색 기능의 균형을, derived field는 저장 시 계산과 조회 시 계산의 균형을 바꿉니다. ‘match_only_text’에서 시작해 ‘derived field’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.
새 기능을 넓게 적용할 때 생기는 문제
- 텍스트 필드는 모두 match_only_text로 바꾸기
- derived field는 저장 공간을 쓰지 않으므로 비용이 없다고 생각하기
- 검색 기능 차이를 확인하지 않고 기존 인덱스를 대체하기
- OpenSearch 버전과 필드별 지원 범위를 무시하기
 |
| match_only_text와 derived field를 선택하는 기준 핵심 판단 흐름 설명용 개념도 |
그림 1. match_only_text와 derived field를 선택하는 기준의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.
필드 유형을 결정하는 순서
- 필드별 실제 검색·집계·정렬·강조 요구를 목록화합니다.
- 저장 공간, 수집 시간, 검색 계산 중 어느 비용을 줄일지 정합니다.
- 대조 인덱스에서 기능 호환성과 대표 쿼리 지연을 비교합니다.
- 자주 쓰는 계산은 저장 필드와 derived field 두 방식으로 비용을 측정합니다.
- 선택 이유와 제한을 매핑 문서에 남기고 인덱스 템플릿을 버전 관리합니다.
두 기능이 줄이는 비용과 늘리는 비용
match_only_text
문서의 존재 여부 중심 검색에 맞춘 텍스트 필드입니다. 위치 정보가 필요한 구문·근접 검색이나 복잡한 점수 계산 요구가 있는지 먼저 확인합니다.
derived field
저장 시 미리 만들지 않은 값을 검색 시 계산해 매핑 변경 부담을 줄일 수 있지만 조회 때 스크립트 계산 비용이 생깁니다.
원본 보존
derived field가 읽을 원본 필드와 형식이 안정적인지 확인합니다. 원본 스키마가 자주 바뀌면 계산 로직도 함께 관리해야 합니다.
쿼리 빈도
매우 자주 쓰는 계산 결과는 수집 시 저장하는 편이 나을 수 있고, 드물거나 실험적인 값은 derived field가 유리할 수 있습니다.
기능 제한 테스트
기존 쿼리를 그대로 실행해 정렬, 집계, 강조, 구문 검색 등 필요한 기능이 유지되는지 검증합니다.
실제 적용과 설명을 대조하기
| 확인 항목 | 질문 |
|---|---|
| 첫 기준: match_only_text | 변경 전에 전제와 목적을 확인했는가? |
| 분리 대상: derived field | 다른 책임과 섞이지 않게 경계를 정했는가? |
| 피할 패턴: 텍스트 필드는 모두 match_only_text로 바꾸기 | 본문에서 경고한 패턴이 남아 있지 않은가? |
| 오류와 복구 | 정상 경로뿐 아니라 실패와 되돌리기도 확인했는가? |
적용 순서 요약
match_only_text는 저장과 검색 기능의 균형을, derived field는 저장 시 계산과 조회 시 계산의 균형을 바꿉니다. 필드별 사용 패턴을 측정해 필요한 곳에만 적용해야 실제 이득이 됩니다.
