인덱스 설계 part 2

* 이전 글에서 이어집니다.

인덱스 설정 part 1

2.3 doc_values

엘라스틱서치의 검색은 term을 보고 역색인에서 문서를 찾는방식이다. 그러나 정렬, 집계, 스크립트 작업 시는 접근법이 다르다.

문서를 보고 필드 내의 텀을 찾는다. doc_values는 디스크를 기반으로 한 자료 구조로 파일 시스템 캐시를 통해 효울적으로 정렬, 집계, 스크립트 작업을 수행한다.

 

text와 annotated_text 타입을 제외한 거의 모든 필드 타입이 doc_values를 지원한다. 정렬, 집계, 스크립트 작업을 할 일이 없는 필드는 doc_values를 끌 수 있다.

PUT [인덱스 이름]/_mapping
{
 "properties" : {
  "notForSort" : {
   "type" : "keyword",
   "doc_values" : false
  }
 }
}

위와 같은 설정으로 doc_values를 끌 수 있고 기본값은 true다.

2.4 fielddata

text타입은 파일 시스템 기반의 캐시인 doc_values를 사용할 수 없다. text 필드를 대상으로 정렬, 집계, 스크립트 작업을 수행할 때에는 fielddata라는 캐시를 사용한다. fielddata를 사용한 정렬이나 집계 등의 작업 시에는 역색인 전체를 읽어 힙 메모리에 올린다. 이러한 동작 방식으로 인해 힙을 순식간에 차지해 out of memory 등 많은 문제를 발생시킬 수 있다. fielddata의 기본값은 비활성화 상태이고 특별한 이유가 있어서 이를 활성화 해야 한다면 다음과 같이 매핑을 하면 된다.

PUT [인덱스 이름]/_mapping
{
 "properties" : {
  "sortableText" : {
   "type" : "text",
   "fielddata" : true
  }
 }
}

text필드의 역색인에는 애널라이저에 의해 분석이 되어 "Hello, World!" 라면 메모리에 올리는 역색인 텀은 이미 분석이 완료된 hello 와 world 라는 텀이다. 이미 분석이 된 내용을 이용해서 집계 등을 수행하기 때문에 원하는 의도와 다른 결과가 나올 수 있고 fielddata를 이용한 집계 등의 무거운 작업은 잦은 out of memory를 발생킬 수 있어 클러스터 전체에 장애를 불러올 수 있다.

특징	doc_values	fielddata
저장위치	디스크	힙 메모리
기본설정	text타입을 제외한 모든 필드에 대해 기본적으로 사용	text 필드에서만 사용
메모리 사용량	상대적으로 적음	많음
성능	고성능(특히 집계 및 정렬 시)	적당
사용 목적	집계, 정렬, 스크립팅	텍스트 분석 및 검색
구성방법	매핑 시 doc_values 속성 사용 (기본적으로 활성화됨)	fielddata 설정
지원 데이터 타입	text타입을 제외한 대부분의 데이터 타입	text

2.5 _source

문서 색인 시점에 엘라스틱서치에 전달된 원본 JSON 문서를 저장하는 메타데이터 필드. 문서 조회 API나 검색 API가 클라이언트에게 반환할 문서를 확정하고 나면 _source에 저장된 값을 읽어 반환한다. _source 필드 자체는 역색인을 생성하지 않기 때문에 검색 대상이 되지 않는다.

• _source 비활성화

_source 필드는 JSON문서를 통째로 담기 때문에 디스크를 많이 사용한다. _source에 데이터를 저장하지 않도록 mappings에 설정할 수 있다.

PUT [인덱스 이름]
{
 "mappings" : {
  "_source" :  {
   "enabled" : false
  }
 }
}

그러나 _source를 비활성화하면 많은 문제가 생길 수 있다. 업데이트와 update_by_query API를 이용할 수 없다. 엘라스틱서치의 세그먼트는 불변이므로 업데이트 작업은 기존 문서를 변경하는 것이 아닌 기존 문서 삭제 후 업데이트된 새 문서를 색인한다. 업데이트 작업은 이 과정에서 기존 문서의 내용을 확인하는데 만약 특정 필드만 부분 업데이트를 해야 한다면 업데이트 요청에 포함된 내용과 기존 문서의 내용을 병합한 뒤 새문서를 색인하는데 기존 문서의 내용에서 읽은 _source가 없기 때문에 업데이트를 할 수 없다.

 

reindex API도 사용할 수 없다. reindex는 원본 인덱스에서 내용을 대상 인덱스에 새로 색인하는 작업인데 매핑이나 샤드 개수 등 동적으로 변경하기 어려운 내용을 바꿔야 할 때 인덱스를 똥째로 새로 색인하거나 할 때 사용한다. reindex 작업도 _source의 원본 JSON 데이터를 읽어 재색인 작업을 수행한다.

 

또한 엘라스틱서치 메이저 버전을 업그레이드할 때도 문제가 된다. 엘라스틱서치는 메이저 버전이 하나 차이나는 인덱스만 읽어 들일 수 있는데 이 이상 차이나는 메이저 버전 업그레이드 전에는 reindex를 수행하여 예전 버전에서 생성된 인덱스를 재생성하여야 한다. _source를 비활성화했다면 불가능하다.

2.6 index

index 속성은 해당 필드의 역색인을 만들 것인지를 지정한다. 기본값은 true다. false로 설정할 경우 해당 필드는 역색인 되지 않으므로 검색 대상이 되지 않는다. 검색의 대상이 되지 않아도 다른 필드를 대상으로 한 검색 결과에는 포함될 수 있다. 문서의 내용 자체는 역색인 여부와 상관없이 _source에 저장되기 때문이다. 또한 역색인을 생성하지 않는 것 뿐이므로 doc_values를 사용하는 타입의 필드라면 정렬이나 집계의 대상으로는 사용할 수 있다.

2.7 enabled

enabled 설정은 object 타입의 필드에만 적용된다. enabled가 false로 지정된 필드는 엘라스틱서치게 파싱조차 하지 않는다. 데이터가 _source에 저장되지만 다른 어느 곳에서도 저장하지 않고 역색인도 되지 않으므로 검색도 불가능하다. 정렬이나 집계의 대상도 될 수 없다.

파싱조차 하지 않으므로 object타입이 아닌 데이터가 들어와도 충돌하지 않는다. 엘라스틱서치는 여러 타입이 혼용되는 배열을 허용하지 않지만 enabled가 false로 지정된 필드에는 아무런 체크를 수행하지 않으므로 타입이 혼용되는 배열도 데이터로 저장할 수 있다.

3. 애널라이저와 토크나이저

애널라이저는 0개 이상의 캐릭터 필터, 1개의 토크나이저, 0개 이상의 토큰 필터로 구성된다. 동작 역시 캐릭터 필터, 토크나이저, 토큰 필터 순서대로 수행된다. 애널라이저에 입력된 텍스트에 캐릭터 필터를 적용하여 문자열을 변형시킨 뒤 토크나이저를 적용하여 여러 term으로 쪼갠다. 쪼개진 토큰의 스트림에 토큰 필터를 적용해서 토큰에 특정한 변형을 가한 결과가 최종적으로 분석 완료한 term이다.

3.1 analyze API

기본적인 standard 애널라이저의 분석 결과를 보자.

요청	결과

text 필드의 데이터 "Hello, HELLO,, World!" 가 애널라이저를 거쳐 최종적으로 hello, hello, world 토큰으로 쪼개진 것을 볼 수 있다.

3.2 캐릭터 필터

캐릭터 필터는 텍스트를 캐릭터의 스트림으로 받아서 특정한 문자를 추가, 삭제, 변경한다. 애널라이저에는 0개 이상의 캐릭터 필터를 지정할 수 있다. 여러 캐릭터 필터가 적영되어 있다면 순서대로 수행된다. 엘라스틱서치에는 다음과 같은 내장 빌트인 캐릭터 필터가 있다.

• HTML strip 캐릭터 필터 : <b>와 같은 html 요소 안쪽의 데이터를 꺼낸다. &apos;같은 html엔티티도 디코딩한다.
• mapping 캐릭터 필터 : 치환할 대상이 되는 문자와 치환 문자를 맵 형태로 선언한다.
• pattern replace 캐릭터 필터 : 정규 표현식을 이용해서 문자를 치환한다.

3.3 토크나이저

토크나이저는 캐릭터 스트림을 받아서 여러 토큰으로 쪼개어 토큰 스트림을 만든다. 애널라이저에는 한 개의 토크나이저만 지정할 수 있다.

• standard 토크나이저 : 가장 기본적인 토크나이저다. Unicode Text Segmentation* 알고리즘을 사용하여 텍스트를 단어 단위로 나눈다. 대부분의 문장 부호가 사라진다. 필드 매핑에 특정 애널라이저를 지정하지 않으면 기본적으로 적용되는 애널라이저다. standard 애널라이저가 standard 토크나이저를 이용한다.
• keyword 토크나이저 : 들어온 텍스트를 쪼개지 않고 그대로 내보낸다. 즉 커다란 단일 토큰을 내보낸다. 특별한 동작을 수행하지 않기 때문에 쓸모없어 보일 수 있지만 여러 캐릭터 필터, 토큰 필터와 함께 조합하면 다양한 커스텀 애널라이저 지정이 가능하다.
• ngram 토크나이저 : 텍스트를 min_gram 값 이상 max_gram 값 이하의 단위로 쪼갠다. 예를 들면 min_gram은 2, max_gram은 3으로 지정하면 hello 라는 텍스트는 "he", "hel", "el", "ell", "ll", "llo"로 총 6개의 토큰으로 쪼개진다. 이런식으로 쪼개진 문자는 공백이 포함될 수도 있고 문장 부호가 포함되어 사실상 활용 의미가 없는 토큰도 포함 될 수 있다. 이런 문제를 피하기 위해 ngram 토크나이저에는 token_chars 라는 속성을 통해 토큰에 포함시킬 문자를 지정할 수 있다. token_chars를 특별히 지정하지 않을 경우 기본 동작은 모든 문자를 허용한다.

종류	설명
Letter	언어의 글자로 분류되는 문자
Digit	숫자로 분류되는 문자
whitespace	띄어쓰기나 줄바꿈 문자 등 공백으로 인식되는 문자
punctuation	!나 " 등 문장 부호
symbol	$와 같은 기호
custom	custom_token_chars 설정을 통해 따로 지정한 커스텀 문자

ngram의 token_chars 속성으로 지정할 수 있는 값

 

ngram 토크나이저는 먼저 token_chars에 지정되지 않은 문자를 기준으로 텍스트를 단어 단위로 쪼갠다. 이렇게 하면 token_chars에 지정되지 않은 문자는 자연스럽게 최종 결과에 포함되지 않는다. 그다음에 각 단어를 min_gram 값 이상 max_gram 값 이하의 길이를 가진 토큰으로 쪼갠다.

 

ngram 토크나이저는 엘라스틱서치에서 RDB의 'like %검색어%'와 유사한 검색을 구현하고 싶을 때, 자동 완성 관련 서비스를 구현하고 싶을 때 주로 이용한다.

 

만약 max_gram 값을 5이상으로 높여서 min_gram과 2이상으로 벌어진다면 분석 시도가 실패한다. 이 제한값은 index.max_ngram_diff 인덱스 설정을 통해 지정할 수 있으며 기본값은 1이다. 이 설정은 인덱스 설정이므로 인덱스를 생성할 때 지정해야 한다. 인덱스를 지정하지 않고 사용하는 analyze API로는 이 값을 변경하며 테스트 할 수 없다.

• edge_ngram 토크나이저 : ngram과 유사한 동작을 수행한다. 먼저 입력된 텍스트를 token_chars에 지정되지 않은 문자를 기준으로 단어 단위로 쪼갠다. 그 다음 min_gram 이상 max_gram 이하의 문자길이로 쪼갠다. 하지만 ngram과는 다르게 생성된 모든 토큰의 시작 글자를 단어의 시작 글자로 고정시켜 생성한다. 예를 들어 min_gram은 2, max_gram은 3일때 "Hello, World" 라는 단어가 있다면 "he", "hel", "wo", "wor" 총 4개로 쪼개진다.
• 그 외 토크나이저
  • letter : 공백, 특수문자 등 언어의 글자로 분류되는 문자가 아닌 문자를 만났을 때 쪼갠다.
  • whitespace : 공백 문자를 만났을 때 쪼갠다.
  • pattern : 지정한 정규표현식을 단어의 구분자로 사용하여 쪼갠다.

3.4 토큰 필터

토큰 필터는 토큰 스트림을 받아서 토큰을 추가, 변경, 삭제한다. 하나의 애널라이저에 토큰 필터는 0개 이상 지정할 수 있다. 토큰 필터가 여러 개 지정된 경우 순차적으로 적용된다.

내장 토큰 필터
lowercase / uppercase	토큰의 내용을 소문자/대문자로 만들어 준다.
stop	불용어를 지정하여 제가할 수 있다. 예) the, a, an, in 등
synonym	동의어 사전 파일을 지정하여 지정된 동의어를 치환한다,
pattern_replace	정규식을 사용하여 토큰의 내용을 치환한다.
stemmer	지원되는 몇몇 언어의 어간 추출을 수행한다. 한국어는 지원하지 않는다.
trim	토큰의 전후에 위치한 공백 문자를 제거한다.
truncate	지정한 길이로 토큰을 자른다.

3.5 내장 애널라이저

standard	standard 토크나이저와 lowercase 토큰 필터구 구성된다. 기본값
simple	letter가 아닌 문자 단위로 토큰을 쪼갠 후 lowercase 토큰 필터 적용
whitespace	공백 단위로 토큰을 쪼갠다,
stop	standard 애널라이저에 stop 토큰 필터를 적용한 애널라이저
keyword	keyword 토크나이저로 구성. 분석을 하지 않고 하나의 큰 토큰을 그대로 반환.
pattern	pattern 토크나이저와 lowercase 토큰 필터로 구성
language	여러 언어의 분석을 지원하지만 한국어는 지원하지 않는다.
fingerprint	증복 검출에 사용할 수 있는 특별한 핑거프린트용 토큰을 생성. 문자열의 "지문"을 생성하여 유사한 문자열을 식별하고 검색 결과를 개선하는 데 도움을 준다. standard 토크나이저 적용 후 lowercase 토큰 필터, ASCII folding 토큰 필터, stop 토큰 필터, fingerprint 토큰 필터를 차례대로 적용한다. 이 중 stop은 기본적으로 비활성화 되어 있다. ASCII folding 토큰 필터는 ASCII에 포함되지 않으면 ASCII 내 동격인 문자가 있으면 동격인 ASCII 문자로 치환해준다. 1. 토큰화: 먼저 입력 문자열을 토큰으로 분리 2. 정규화: 토큰을 소문자로 변환하거나 불필요한 문자를 제거하여 일관성을 확보 3. 지문 생성: 정규화된 토큰을 기반으로 해시 값이나 특정 알고리즘을 사용하여 각 문자열의 고유한 지문을 생성 4. 유사도 비교: 생성된 지문을 비교하여 유사한 문자열을 그룹화 5.검색 및 집계: 지문을 사용하여 유사한 문서를 검색하거나 집계 작업을 수행할 수 있음

3.6 애널라이저를 매핑에 적용

각 필드의 매핑에 애널라이저를 적용하는 방법

PUT [인덱스 이름]
{
  "settings": {
    "analysis": {
      "analyzer": {
        "default" :{
          "type" : "keyword"
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "defaultText" : {
        "type" : "text"
      },
      "standardText" : {
        "type": "text",
        "analyzer": "standard"
      }
    }
  }
}

index.settings.analysis.analyzer 설정에는 커스텀 애널라이저를 추가할 수 있다. default라는 이름으로 애널라이저를 지정하면 기본 애널라이저를 변경할 수 있다. 위 예제에서는 기본값인 standard 애널라이저를 keyword 애널라이저로 변경하였다.

 

매핑 부분에서 text타입의 defaultText 필드와 standardText 필드를 지정했다. text 타입이므로 애널라이저가 적용되고 따로 애널라이저를 지정하지 않은 defaultText는 keyword 애널라이저가 적용된다. standardText는 analyzer 속성으로 standard를 직접 지정했으므로 standard 애널라이저가 적용된다.

3.7 커스텀 애널라이저

커스텀 애널라이저는 캐릭터 필터, 토크나이저, 토큰 필터를 원하는 대로 조합해 지정한다.

PUT analyzer_test2
{
  "settings": {
    "analysis": {
      "char_filter": {
        "my_char_filter": {
          "type": "mapping",
          "mappings": [
            "i. => 1.",
            "ii. => 2.",
            "iii. => 3.",
            "iv. => 4."
          ]
        }
      },
      "analyzer": {
        "my_analyzer": {
          "char_filter": [
            "my_char_filter"
          ],
          "tokenizer": "whitespace",
          "filter": [
            "lowercase"
          ]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "myText": {
        "type": "text",
        "analyzer": "my_analyzer"
      }
    }
  }
}

위 예시는 analyzer_test2라는 인덱스에 my_char_filter라는 커스텀 캐릭터 필터를 선언했다. 그 뒤 my_char_filter 캐릭터 필터, whitespace 토크나이저, lowercase 토큰 필토를 조합하여 my_analyzer라는 커스텀 애널라이저를 선언했다.

3.8 플러그인 설치를 통한 애널라이저 추가와 한국어 형태소 분석

기본 내장 애널라이저에 한국어 형태소 분석기는 존재하지 않는다. 하지만 엘라스틱서치에서 제공하는 공식 nori 플러그인을 설치하면 한국어를 분석할 수 있다.

 

bin/elasticsearch-plugin install analysis-nori     

플러그인을 설치할 때는 클러스터를 구성하는 모든 노드에 설치해야 한다. 클러스터를 구성하는 모든 노드에 위의 명령어를 실행하고 클러스터를 재기동한다.

요청	결과

3.9 노멀라이저

노멀라이저는 애널라이저와 비슷한 역할을 하지만 적용 대상이 text타입이 아닌 keyword타입이다. 또한 애널라이저와는 달리 단일 토큰을 생성한다.

 

노멀라이저는 토크나이저 없이 캐릭터 필터, 토큰 필터로만 구성된다. 또한 앞에서 살펴봤던 캐릭터 필터와 토큰 필터를 모두 조합할 수 있는 것은 아니다. 최종적으로 단일 토큰만 생성해야 하기 때문에 ASCII folding, lowercase, uppercase 등 글자 단위로 작업을 수행하는 필터만 사용 가능 하다.

 

엘라스틱서치가 제공하는 기본 노멀라이저는 lowercase밖에 없다. 다른 방법으로는 keyword 타입의 필드를 처리하려면 커스텀 노멀라이저를 조합해 사용해야 한다.

PUT normalizer_test
{
  "settings": {
    "analysis": {
      "normalizer": {
        "my_normalizer": {
          "type": "custom",
          "char_filter": [],
          "filter": [
            "asciifolding",
            "uppercase"
          ]
        }
      }
    }
  },
 "mappings": {
    "properties": {
      "myNormalizerKeyword": {
        "type": "keyword",
        "normalizer": "my_normalizer"
      },
      "lowercaseKeyword": {
        "type": "keyword",
        "normalizer": "lowercase"
      },
      "defaultKeyword": {
        "type": "keyword"
      }
    }
  }
}

myNormalizerKeyword 필드에 my_normalizer 커스텀 노멀라이저를, lowercaseKeyword에는 lowercase 노멀라이저를 적용했다.

defaultKeyword는 특별한 설정을 하지 않았다.

 

다음과 같은 예시로 요청을 보냈을 때 어떻게 동작하는지 테스트 해보자.

요청	결과
GET normalizer_test/_analyze {   "field": "myNormalizerKeyword",   "text": "Wórld!" }	{   "tokens": [     {       "token": "WORLD!",       "start_offset": 0,       "end_offset": 6,       "type": "word",       "position": 0     }   ] }
GET normalizer_test/_analyze {   "field": "lowercaseKeyworld",   "text": "Wórld!" }	{   "tokens": [     {       "token": "wórld",       "start_offset": 0,       "end_offset": 5,       "type": "<ALPHANUM>",       "position": 0     }   ] }
GET normalizer_test/_analyze {   "field": "defaultKeyword",   "text": "Wórld!" }	{   "tokens": [     {       "token": "Wórld!",       "start_offset": 0,       "end_offset": 6,       "type": "word",       "position": 0     }   ] }

4. 템플릿

템플릿이란 특정 패턴을 가진 인덱스가 생성될 때 자동으로 설정을 적용하는 기능이다. 템플릿을 사용하면 인덱스 생성 시마다 설정을 반복 입력할 필요가 없어 효율성을 높이고, 실수를 줄일 수 있다.

4.1 인덱스 템플릿

PUT _index_template/my_template
{
  "index_patterns": [
    "pattern_test_index-*",
    "another_pattern-*"
  ],
  "priority": 1,
  "template": {
    "settings": {
      "number_of_shards": 2,
      "number_of_replicas": 2
    },
    "mappings": {
      "properties": {
        "myTextField": {
          "type": "text"
        }
      }
    }
  }
}

index_patterns 부분에는 인덱스 패턴을 지정한다. 새로 생성되는 인덱스의 이름이 이 패턴에 부합하면 이 템플릿에 맞춰 인덱스가 생성된다. 인덱스 패턴에는 *와 같은 와일드카드 문자를 사용할 수 있다. priority 값을 이용하면 여러 인덱스 템플릿간 우선 순위를 조정할 수 있다. priority 값이 높을수록 우선순위가 높다.

 

PUT pattern_test_index-1

위와 같은 명령어를 실행하고 인덱스를 확인해 보자.

요청	결과
GET pattern_test_index-1

4.2 컴포넌트 템플릿

인덱스 템플릿을 많이 만들어 사용하다 보면 템플릿 간 중복되는 부분이 생긴다. 이런 중복 부분을 재사용할 수 있는 작은 템플릿 블록으로 쪼갠 것이 컴포넌트 템플릿이다.

PUT _component_template/timestamp_mappings
{
  "template": {
    "mappings": {
      "properties": {
        "timestamp": {
          "type": "date"
        }
      }
    }
  }
}

PUT _component_template/my_shard_settings
{
  "template": {
    "settings": {
      "number_of_shards": 2,
      "number_of_replicas": 2
    }
  }
}

다음과 같이 2개의 컴포넌트 템플릿을 만들었다.

 

timestamp_mappings 컴포넌트 템플릿에는 매핑에 timestamp라는 이름의 필드 설정을 담았고, my_shard_settings 컴포넌트 템플릿에는 주 샤드와 레플리카 개수를 2개로 설정하는 부분을 담았다.

 

이후 인덱스 템플릿을 생성할 때 재사용할 컴포넌트 템플릿 블록을 composed_of 항목에 넣으면 된다.

PUT _index_template/my_template2
{
   "index_patterns": ["timestamp_index-*"],
   "composed_of": ["timestamp_mappings", "my_shard_settings"]
}

 

인덱스를 생성해보자

PUT timestamp_index-001

요청	결과
GET timestamp_index-001

4.3 레거시 템플릿

인덱스 템플릿과 컴포넌트 템플릿 API는 엘라스틱서치 버전 7.8.0 버전부터 추가된 기능이다. 이전 버전에서 사용하던 템플릿 API는 레거시가 되었다. 이번 버전 템플릿은 _index_template 대신 _template을 사용하며, 컴포넌트 템플릿을 조합할 수 없다는 점을 제외하면 사실상 동일한 기능이다.

4.4 동적 템플릿

동적 템플릿은 인덱스에 새로운 필드가 추가될 때 자동으로 필드 매핑을 설정하는 기능이다. 인덱스 매핑에 명시적으로 정의되지 않은 필드가 문서에 포함될 때, 동적 템플릿은 필드 이름 패턴이나 데이터 유형에 따라 해당 필드에 적절한 매핑을 적용한다.

PUT _index_template/dynamic_mapping_template
{
  "index_patterns": ["dynamic_mapping*"],
  "priority": 1,
  "template": {
    "settings": {
      "number_of_shards": 2,
      "number_of_replicas": 2
    },
    "mappings": {
      "dynamic_templates": [
        {
          "my_text": {
            "match_mapping_type": "string",
            "match": "*_text",
            "mapping": {
              "type": "text"
            }
          }
        },
        {
          "my_keyword": {
            "match_mapping_type": "string",
            "match": "*_keyword",
            "mapping": {
              "type": "keyword"
            }
          }
        }
      ]
    }
  }
}

인덱스 템플릿을 생성할 때 사전 정의하는 매핑에 dynamic_templates라는 속성으로 동적 템플릿의 내용을 정의했다. 새로운 필드가 들어올 때 그 데이터가 문자열 타입이라면 필드의 이름을 확인하고 _text로 끝나면 text타입, _keyword로 끝나면 keyword타입으로 지정한다.

 

동적 템플릿 기능을 활용하여 새로운 필드에 템플릿을 적용할 때 다음과 같은 조건을 확인하도록 지정할 수 있다.

• match_mapping_type: 새로 들어온 데이터 타입을 JSON파서를 이용해 확인한다. JSON파서는 long과 integer의 차이 등은 인지할 수 없기 때문에 더 큰 범위의 데이터타입 이름을 사용한다. match_mapping_type 으로 지정할 수 있는 값
   - boolean, double, long, string, object, date
• match / unmatch: match는 필드의 이름이 지정된 패턴과 일치하는지 확인한다. unmatch는 필드 이름이 지정된 패턴과 일치하지 않을 때 적용한다
   - match_pattern 옵션을 regex로 지정하면 단순한 와일드카드 매치를 수행하는 것이 아닌 정규표현식을 이용한 매치를 수행한다.
• path_match / path_unmatch: match / unmatch와 동일하게 동작하지만 필드 이름으로 마침표를 사용한 전체 경로를 이용한다.
  ex) my_object.name.text*

5. 라우팅

라우팅은 엘라스틱서치가 인덱스를 구성하는 샤드 중  번 샤드를 대상으로 작업을 수행할지 지정하기 위해 사용한다. 라우팅 값은 문서를 색인할 때 문서마다 하나씩 지정할 수 있다. 작업 대상 샤드 번호는 지정된 라우팅 값을 해시 후 주 샤드의 개수로 나머지 연산을 수행한 값이 된다. 라우팅 값을 지정하지 않고 색인을 하면 _id값이 라우팅 기본값이 된다. 색인 시 라우팅 값을 지정했다면 조회, 업데이트, 삭제, 검색 등의 작업에서도 똑같이 라우팅을 지정해야 한다.

PUT routing_test
{
  "settings": {
    "number_of_shards": 5,
    "number_of_replicas": 1
  }
}


PUT routing_test/_doc/1?routing=myid
{
  "login_id": "myid",
  "comment": "hello world",
  "created_at": "2024-05-22T22:00:000Z"
}

새로운 인덱스를 생성하고 문서를 색인한다.

 

5개의 샤드를 가진 인덱스를 생성하고 myid라는 값을 라우팅 값으로 지정하여 문서를 색인한다. 엘라스틱서치에너는 검색할 때 라우팅 값을 기입하지 않으면 전체 샤드를 대상으로 검색을 수행하고, 라우팅 값을 명시하면 단일 샤드를 대상으로 검색한다.

 

다음과 같이 요청을 한다.

GET routing_test/_search // 라우팅 값 x

GET routing_test/_search?routing=myid // 라우팅 값 o

라우팅 값 x	라우팅 값 o

오른쪽의 경우 라우팅 값을 이용하여 샤드 숫자를 정확히 특정한 뒤 단일 샤드를 대상으로 검색을 하였다. 라우팅 값을 정확히 명시했기 때문에 원하는 결과를 받았지만 라우팅 값을 다른 값으로 지정한다면 검색 결과에 원하는 문서가 포함되지 않을 수 있다. 문서가 저장된 샤드가 아닌 다른 샤드에 검색 요청이 들어가기 때문이다.

 

인덱스 내 _id 값의 고유성 검증은 샤드 단위로 보장된다. 색인, 조회, 업데이트, 삭제 작업이 모두 라우팅 수행 이후 단일 샤드 내에서 이뤄지기 때문이다. 라우팅 값이 다르게 지정되면 한 인덱스 내 같은 _id를 가진 문서가 여러 개 생길 수도 있다.

 

5.1 인덱스 매핑에서 라우팅을 필수로 지정하기

PUT routing_test2
{
  "mappings": {
    "_routing": {
      "required": true
    }
  }
}

위 예시처럼 라우팅 required 값을 true로 지정하면 라우팅 값이 명시되지 않은 색인, 조회, 업데이트, 삭제 요청은 실패하게 된다.