[DB] ElasticSearch Index 설정과 텍스트 분석

Index API의 개요

ElasticSearch를 할 때 가장 기초가 되는 부분이다. 물론 데이터를 삽입할 때, Index가 없으면 자동으로 생성하지만... 사실 세부적으로 검색을 튜닝하려면 Index에 대한 세부적인 설정은 필수이다.

 

Index API는 Index를 생성하고 설정을 하는 역할을 한다. 이 때, 데이터 모델링을 진행한다. 이때, 한번 생성한 맵핑 타입은 변경할 수 없으니 주의할 것!

 

Index 설정 요청은 아래처럼 생겼다. 크게 setting 부분과 mapping 부분 이렇게 두개로 나뉜다고 보면 된다.

PUT /complex_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "korean_analyzer": {
          "type": "custom",
          "tokenizer": "nori_tokenizer",
          "filter": ["lowercase", "nori_part_of_speech"]
        },
        "english_analyzer": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase", "english_stemmer"]
        },
        "keyword_analyzer": {
          "type": "keyword"
        }
      },
      "filter": {
        "english_stemmer": {
          "type": "stemmer",
          "language": "english"
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "english_analyzer"
      },
      "description": {
        "type": "text",
        "analyzer": "korean_analyzer"
      },
      "tags": {
        "type": "keyword"
      },
      "published_date": {
        "type": "date",
        "format": "yyyy-MM-dd"
      },
      "comments": {
        "type": "nested",
        "properties": {
          "user": {
            "type": "keyword"
          },
          "comment": {
            "type": "text",
            "analyzer": "korean_analyzer"
          }
        }
      }
    }
  }
}

 

Setting (인데스 설정 관련)

setting에서는 인덱스의 구성 설정을 정의하는 부분이. 샤드와 복제본의 개수, 커스텀 형태소 분석기 등을 지정할 수 있다. setting 설정을 전부 다루기에는 너무 방대해서, 실제 비즈니스 로직과 크게 관련있는 Tokenizer와 Analyzer 2개 위주로 알아볼 것이다.

 

Tokenizer

Tokenizer는 형태소 분석을 어떻게 할 것인가에 대한 것이다. 어떤 데이터가 들어왔을때 (ex: String 문장 데이터) 해당 데이터를 특정 기준으로 쪼갠 조각을 Token이라고 생각하면 된다. Tokenizer는 이 Token을 어떤 기준으로 나눌 것인가?에 관한 것이다. 수많은 Tokenizer가 있지만, 중요한 몇개만 다뤄보고자 한다.

 

1. Standard

 

Default 값. 띄어쓰기를 기준으로 나누고, 특수문자가 빠짐. mapping field에서 analzyer 설정 안하면 이게 기본이 된다.

ex) 오늘의 포켓몬은 뭘까요? -> "오늘의", "포케몬은", "뭘까요"

 

2. WhiteSpace

 

오직 띄어쓰기로만 구분한다. 위 Standard는 특수문자가 빠지는 것과 달리, WhiteSpace는 포함된다.

 

3. Keyword

 

들어온 데이터가 통으로 Token이 된다. 즉, 쪼개지 않는다.

 

4. uax_url_email

 

이메일 포멧을 기준으로 나눈다.

ex) mclub901@gmail.com -> "mclub901", "gmail.com"

 

5. N-gram

 

인공지능 분야에서 N-Gram 언어 모델이라고 있다. 이는 들어온 텍스트를 단어/음절 단위로 분리해서 각 단위를 기반으로 문맥을 이해하고 다음 단어를 예측하는 모델을 칭한다. ElasticSearch도 이 개념을 채택했다. N-gram Tokenizer를 사용하면 텍스트를 특정 길이 단위로 형태소 분할이 가능하다.

 

예시로 위에 사진을 봐보자. 만일 우리가 쪼개는 길이 단위인 N을 2로 설정한 경우 ‘house’ 라는 단어는 ‘ho’, ‘ou’, ‘us’, ‘se’ 네 개의 토큰으로 나누어 Index에 저장된다. 

"tokenizer": {
        "my_tokenizer": {
          "type": "ngram",
          "min_gram": 2,
          "max_gram": 10,
          "token_chars": [
            "letter",
            "digit"
          ]
        }
      }

위에 코드 처럼 쪼갤 최소 길이와 최대 길이를 지정할 수 있다. 이렇게 하면, 해당 텍스트는 2글자, 3글자, 4글자... 10글자 단위로 형태소가 분할되어 저장된다.

 

이를 어떻게 활용할 수 있을까? 바로 검색어 자동 완성에 활용할 수 있다. house라는 글자를 min = 2, max = 5로 쪼갰다면, ho라는 글자만 치더라도 house가 자동 완성이 될 수 있는 것이다.

 

6. Edge-Ngram

 

일반적으로 검색할 때는 단어를 앞에서부터 입력하게 된다. 그리고 자동완성 키워드는 주로 입력한 문자열로 시작하는 키워드를 가져오게 된다. 즉, N-Gram으로 생성한 ‘ou’, ‘us’, ‘se’와 같은 토큰은 그다지 큰 효용성이 없고, 오히려 ‘h’, ‘ho’, ‘hou’와 같이 쪼개는 방법이 더 효율적일 수 있다는 의미이기도 하다. 따라서, Edge N-Gram은 N-Gram과 유사하게 입력받은 텍스트를 길이 N의 문자열로 분리하지만, 대신 앞에서부터 연속한 N개의 문자열만 가져온다.

 

7. 한글 형태소 분석기

 

한글은 원래 다루기 힘든 데이터이다. 왜냐하면 자동 완성을 예시로 들어보면 국이라는 단어를 입력하면 ‘국밥’ 또는 ‘구글’이라는 데이터가 나온다. 즉, ㄱ이 종성이 될 수도 있고 초성이 될 수도 있기 때문에 한글 형태소 분리는 매우 중요하다.

 

따라서, 한글을 위한 Tokenizer를 활용해야된다. 대표적인 것이 Nori 형태소 분석기가 있다.

 

Analzyer

analzyer는 이 tokenizer를 이용해서 색인 및 검색 가능한 형태로 변환하는 프로세스에 대한 정의이다. 이걸 밑에 mapping field에 가져다써서 이 필드는 형태소 분석이 어떻게 하도록 해라라고 정의할 수 있다.

 

 

다음 시간에는 mapping에 대해서 다뤄볼 것이다.