검색용 데이터에 정확한 ID 조회와 본문 검색이 함께 있습니다. Elasticsearch의 mapping과 shard 수를 어떻게 정해야 하나요?

Elasticsearch의 mapping은 필드가 검색·정렬·집계될 때 어떤 타입과 분석기를 사용할지 정하는 스키마이고, shard는 인덱스를 나눠 저장·검색하는 단위입니다. 정확한 ID 조회와 본문 검색이 함께 있으면 ID는 분석되지 않은 keyword, 본문은 언어 분석이 적용되는 text로 분리하는 것이 일반적인 출발점입니다. shard 수를 늘리는 것만으로 잘못된 필드 타입이나 토큰화를 고칠 수는 없습니다.

필드 의미를 질의에서 거꾸로 설계합니다

상품 ID나 테넌트 ID를 정확히 비교·정렬·집계하려면 토큰으로 쪼개지는 text보다 원문 전체를 하나의 값으로 취급하는 keyword가 맞습니다. 설명·제목의 본문 검색은 text와 분석기를 사용하되, 같은 문자열에 정확 비교·정렬도 필요하면 multi-field로 keyword 표현을 추가할 수 있습니다. 숫자·날짜는 문자열로 넣지 않고 범위와 정렬 요구에 맞는 타입으로 선언합니다. 동적 필드가 계속 생성되면 mapping 폭증과 클러스터 상태·메모리 부담이 생길 수 있어 허용 필드와 동적 템플릿을 제한하겠습니다.

doc values와 역색인은 용도가 다릅니다. 본문 검색은 역색인 구조를 주로 사용하고, 정렬·집계는 doc values와 메모리·디스크 비용을 사용합니다. 높은 카디널리티 집계, 큰 keyword 값, 분석기 선택은 검색 결과뿐 아니라 heap·세그먼트·집계 지연에 영향을 줍니다. 필드가 지금 검색되지 않는다고 모두 index:false로 끄는 것도 나중의 요구와 재색인 비용을 함께 봐야 합니다.

shard 수는 저장 크기와 운영 시간으로 정합니다

샤드가 많으면 검색이 여러 단위로 병렬화될 수 있지만, 한 요청이 여러 샤드에 fan-out해 각 샤드의 검색·조정·정렬 비용이 생깁니다. 작은 샤드를 과도하게 만들면 클러스터 상태·세그먼트·파일 핸들·heap 관리 비용이 늘고, 너무 큰 샤드는 복구·재배치와 장애 후 복원 시간이 길어집니다. primary와 replica 수는 가용성·읽기 병렬성·저장 용량을 함께 계산하겠습니다.

Elasticsearch 버전과 노드 역할·heap·디스크에 따라 적정 샤드 크기와 검색 비용이 달라지므로 고정 숫자를 외우지 않겠습니다. 실제 문서 분포와 대표 본문·ID·집계 쿼리로 heap, CPU, 검색 p99, 색인 처리량, refresh 지연, 재배치·복구 시간을 측정합니다. mapping 변경으로 재색인이 필요하면 새 인덱스를 만들고 alias를 검증 후 전환해 원본 조회와 검색 가시성을 분리합니다. 결론은 질의 계약과 데이터 표현을 먼저 정하고, 그 뒤 샤드 수를 운영 가능한 범위로 맞추는 것입니다.

샤드 수는 인덱스 생성 뒤 쉽게 줄이기 어렵고, 과도한 primary를 나중에 합치려면 재색인이 필요할 수 있습니다. 따라서 예상 문서 수·평균/최대 문서 크기·색인 속도·복구 시간의 상한을 먼저 잡고, 초기에는 보수적인 수와 alias 전환 여지를 둡니다. 검색 fan-out이 넓어지면 샤드별 결과를 조정 노드가 병합하는 비용도 커집니다. 정확 ID 조회는 routing으로 줄일 수 있지만 routing 편중·검색 범위 제약이 생기므로 무조건 적용하지 않겠습니다.