작업공간

Synonym Token Filter

Analyzer의 Filter에 사용가능한 필터로, 동의어를 처리할 수 있는 필터

(동이어나 불용어, 사용자 사전과 관련된 부분은 나중에 더 Deep하게 보고, 일단 해당 필터에 대해서만 서술함)

Parameters

synonyms : 동의어로 등록(사용)할 단어

synonmyms_path : 파일로 관리할 경우 Elasticearch server의 config 폴더 아래에 생성/지정

1. 분석기 정의

PUT /test_index_for_synonym
{
  "settings": {
    "analysis": {
      "analyzer": {
        "synonym_analyzer": {
          "tokenizer": "whitespace",
          "filter": [
            "synonym_filter"
          ]
        }
      },
      "filter": {
        "synonym_filter": {
          "type": "synonym",
          "synonyms" : [
            "Harry => 해리"
          ]
        }
      }
    }
  }
}

2. 분석 Start

POST test_index_for_synonym/_analyze
{
  "analyzer": "synonym_analyzer",
  "text": "Harry Potter and the Chamber of Secrets"
}

3. 분석 결과

{
  "tokens" : [
    {
      "token" : "해리",
      "start_offset" : 0,
      "end_offset" : 5,
      "type" : "SYNONYM",
      "position" : 0
    },
    {
      "token" : "Potter",
      "start_offset" : 6,
      "end_offset" : 12,
      "type" : "word",
      "position" : 1
    },
    {
      "token" : "and",
      "start_offset" : 13,
      "end_offset" : 16,
      "type" : "word",
      "position" : 2
    },
    {
      "token" : "the",
      "start_offset" : 17,
      "end_offset" : 20,
      "type" : "word",
      "position" : 3
    },
    {
      "token" : "Chamber",
      "start_offset" : 21,
      "end_offset" : 28,
      "type" : "word",
      "position" : 4
    },
    {
      "token" : "of",
      "start_offset" : 29,
      "end_offset" : 31,
      "type" : "word",
      "position" : 5
    },
    {
      "token" : "Secrets",
      "start_offset" : 32,
      "end_offset" : 39,
      "type" : "word",
      "position" : 6
    }
  ]
}

일단 Local에서 ES와 Kibana를 Run 한 뒤 이것저것 테스트한 내용을 서술한다.

(별 것 아닌 내용이지만 남겨놓는게 나을 것 같아서)

POST test_index/_analyze
{
  "analyzer": "standard",
  "text": "월, 화, 수, 목, 금, 토, 일"
}

// Result
{
  "tokens" : [
    {
      "token" : "월",
      "start_offset" : 0,
      "end_offset" : 1,
      "type" : "<HANGUL>",
      "position" : 0
    },
    {
      "token" : "화",
      "start_offset" : 3,
      "end_offset" : 4,
      "type" : "<HANGUL>",
      "position" : 1
    },
    {
      "token" : "수",
      "start_offset" : 6,
      "end_offset" : 7,
      "type" : "<HANGUL>",
      "position" : 2
    },
    {
      "token" : "목",
      "start_offset" : 9,
      "end_offset" : 10,
      "type" : "<HANGUL>",
      "position" : 3
    },
    {
      "token" : "금",
      "start_offset" : 12,
      "end_offset" : 13,
      "type" : "<HANGUL>",
      "position" : 4
    },
    {
      "token" : "토",
      "start_offset" : 15,
      "end_offset" : 16,
      "type" : "<HANGUL>",
      "position" : 5
    },
    {
      "token" : "일",
      "start_offset" : 18,
      "end_offset" : 19,
      "type" : "<HANGUL>",
      "position" : 6
    }
  ]
}

POST _analyze
{
// analyzer를 지정하지 않을 경우 "standard" analyzer 적용
  "text": "자, 과연 어떻게 나올까? 에라 모르겠다... I don't know!"
}

// Result
{
  "tokens" : [
    {
      "token" : "자",
      "start_offset" : 0,
      "end_offset" : 1,
      "type" : "<HANGUL>",
      "position" : 0
    },
    {
      "token" : "과연",
      "start_offset" : 3,
      "end_offset" : 5,
      "type" : "<HANGUL>",
      "position" : 1
    },
    {
      "token" : "어떻게",
      "start_offset" : 6,
      "end_offset" : 9,
      "type" : "<HANGUL>",
      "position" : 2
    },
    {
      "token" : "나올까",
      "start_offset" : 10,
      "end_offset" : 13,
      "type" : "<HANGUL>",
      "position" : 3
    },
    {
      "token" : "에라",
      "start_offset" : 15,
      "end_offset" : 17,
      "type" : "<HANGUL>",
      "position" : 4
    },
    {
      "token" : "모르겠다",
      "start_offset" : 18,
      "end_offset" : 22,
      "type" : "<HANGUL>",
      "position" : 5
    },
    {
      "token" : "i",
      "start_offset" : 26,
      "end_offset" : 27,
      "type" : "<ALPHANUM>",
      "position" : 6
    },
    {
      "token" : "don't",
      "start_offset" : 28,
      "end_offset" : 33,
      "type" : "<ALPHANUM>",
      "position" : 7
    },
    {
      "token" : "know",
      "start_offset" : 34,
      "end_offset" : 38,
      "type" : "<ALPHANUM>",
      "position" : 8
    }
  ]
}

elasticsearch 7.7 버전에서는 create index 시 analysis를 setting 안으로 넣어주어야 하는 것 같다.

(html_strip Character Filter 예제)

PUT /test_index_for_html_strip
{
  "settings": {
    "index" : {
      "number_of_shards": 5,
      "number_of_replicas": 1
    },
    "analysis": {
    "analyzer": {
      "custom_html_strip_analyzer": {
        "type": "custom",
        "char_filter": [
          "html_strip"
        ],
        "tokenizer": "standard",
        "filter": [
          "lowercase"
        ]
      }
    }
  }
  }
}
POST /test_index_for_html_strip/_analyze
{
  "analyzer": "custom_html_strip_analyzer", 
  "text": "<B>Elasticsearch</B> is cool! <br>"
}

// Result
{
  "tokens" : [
    {
      "token" : "elasticsearch",
      "start_offset" : 3,
      "end_offset" : 20,
      "type" : "<ALPHANUM>",
      "position" : 0
    },
    {
      "token" : "is",
      "start_offset" : 21,
      "end_offset" : 23,
      "type" : "<ALPHANUM>",
      "position" : 1
    },
    {
      "token" : "cool",
      "start_offset" : 24,
      "end_offset" : 28,
      "type" : "<ALPHANUM>",
      "position" : 2
    }
  ]
}

문자 그대로, '정적색인'과 '동적색인'이다.

서술하기에 앞서 이쪽을 참고하였다. (이곳을 비롯한 여러곳에서 배웠다는 표현이 더 정확하다.)

https://searchtool.tistory.com/11

정적색인 = 전체색인 = static index

색인을 시도하는 시점 이전의 데이터를 수집/색인

만약 특정 운영환경에서 점검 등으로 새로운 데이터가 들어올 수 없는 상황일 경우, 별도의 증분색인없이 데이터를 색인할 수 있을 것이다.

동적색인 = 증분색인 = dynimic index

전체색인 완료 시점 이후에 추가된 데이터를 수집/색인

보통은 운영중이거나, 주기적으로 특정 데이터(로그 등)가 유입될 경우, 배치로 특정 시점의 데이터를 색인하는 것이라 이해된다.

메뉴얼 색인 = manual index

데이터의 PK 혹은 특정 고유값을 통한 데이터 재수집/재색인

이 경우에는 특정 document의 _version이 달라지지 않을까 싶다.

(동적색인의 경우에도 마찬가지일것 같다만)

static index

아주 간단하게, 특정 테이블(DB)에 있는 데이터를 색인할 경우, 해당 색인을 시작하기 이전 row 만큼 데이터를 수집하고 색인한다.

아마도 Elasticsearch의 logstash에서 이런 모양

(ex. select * from some_table)

dynamic index

사실 대부분의 운영환경이 이렇지 않을까 싶은데, 두 가지 방법이 있다고 한다.

1. 특정 날짜 (timestamp 등) 기준 수집/색인

2. CRUD 발생 시 기록 수집/색인 방법이 있다.

근데 지금보면, 내가 다니던 직장의 경우엔 두 가지 방법이 같이 쓰였던것 같다. (내가 구현하진 않았지만)

1. 데이터에 대해 CRUD 행위가 일어나면, 해당 데이터가 변경된 시간정보를 Update 한다.

2. 특정 시간간격만큼 배치로 마지막 색인 시점을 Tracking하여 해당 시점 이후에 변경된 데이터를 수집/색인한다.

여기서, 1에서 변경하는 값이 데이터의 변경시각이 아닌 PK를 어딘가(= Search용 Queue)에 기록한다면 메뉴얼 색인이 될 듯하다.

색인할 필드의 데이터를 어떻게 저장할지에 대한 다양한 옵션을 제공

analyzer

해당 필드의 데이터를 '형태소 분석'하는 파라미터

색인과 검색 시 지정한 분석기로 형태소 분석을 수행

text 타입의 필드는 anlyzer 매핑 파라미터를 기본적으로 사용해야함 (type이 사라진 ES 버전 이후로는 따로 확인해야함)

별도로 분석기를 지정하지 않을 경우 Standard Analyzer로 지정됨

normalizer

term query에 분석기를 사용하기 위해 사용

ex) keyword type의 경우 cafe, Cafe는 서로 다른 문자로 인식되지만,
해당 유형을 normalizer를 통해 분석기에 asciifolding과 같은 필터를 사용하면 같은 데이터로 인식되게 할 수 있음

boost

필드에 가중치(Weight)를 부여함

가중치에 따라 유사도 점수(_score)가 달라지기 때문에 boost를 설정하면 검색 결과의 노출 순서에 영향을 줄 수 있음

만약 색인 시점에 boost 설정을 하면, re-indexing 하지 않는 이상 가중치를 변경할 수 없음

때문에 색인이 아닌 검색 시점에만 사용하는 것을 권장함 (ES 특정버전 이상부터는 색인 시점에 boost 설정을 할 수 없음)

coerce

색인 시 자동 변환 허용 여부

ex) "10" 숫자 형태의 문자열이 integer 타입의 필드에 들어올 경우 ES가 자동으로 형변환해 정상적으로 색인을 수행함
coerce 설정이 off 되었을 경우 색인 실패

Elasticsearch는 RESTful 방식의 API를 제공하며, 이를 통해 JSON 기반으로 통신함

기본적으로 http 통신을 위해 9200 port를 사용함

- Indices API : 인덱스 관리

- Document API : 문서 C/U/D

- Search API : 문서 Read

- Aggregation API : 문서 통계

Index 생성

Index 생성 시 mapping을 지정할 수 있는데, 이는 변경될 수 없으며 변경이 필요할 시 데이터를 삭제하고 재색인 하는 수밖에 없다.

PUT /character
{
	"settings": {
    	"number_of_shards": 3,
        "number_of_replicas": 2
    },
    "mappings": {
    	"_doc": {
        	"properties": {
            	"level": { "type" : "integer" }	// 현재 시점 ES버전에서는 Type을 제공하지 않음
                "name": { "type" : "text" }
                // ... 생략 ...
            }
        }
    }
}

// 결과
{
  "acknowledged": true,
  "shards_acknowledged": true,
  "index": "character"
}

Index 삭제

DELETE /character

// 결과
{
  "acknowledged": false
}

Doc 생성

POST /character/_doc/1
{
  "level": 10,
  "name": "게임 캐릭터1"
}

// 결과
{
  "_index": "character",
  "_type": "_doc",
  "_id": "1",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 2,
    "failed": 0
  }
}

Cluster = 물리적인 Node Insatnce들의 모임 = 모든 노드의 검색과 색인 작업을 관장하는 '논리적인' 개념

RDBMS에서는 모든 요청을 Server 한 대에서 처리하고 결과를 제공하지만,

Elasticsearch에서는 다수의 서버로 분산처리 후 결과를 제공할 수 있음

Node의 종류

 -> 각 노드는 한 가지 유형으로 동작할 수도, 여러 개의 유형으로 동작할 수도 있음

1. Master Node

 = Cluster 관리

 = 노드 추가, 제거 등 Cluster 전반적인 부분 관리

2. Data Node

 = 실질적인 데이터 제공

 = 검색, 통계 등 데이터 관련 작업 수행

3. Coordinating Node

 = 사용자의 요청만 받아서 처리

 = ?? 무슨소리?

 = if Cluster 관련 요청 -> Master Node에 전달;

    else if Data 관련 요청 -> Data Node에 전달;

 = 일종의 로드밸런싱 역할 수행?

4. Ingest Node

 = 문서의 전처리 작업 담당

 = 인덱스 생성 전 문서의 형식을 다양하게 변경 가능

 = 사용해보지 않아서 좀 더 공부 필요

Master Node

다수의 노드를 마스터 노드로 설정하여도 결과적으로 하나의 노드만이 마스터 노드로 선출, 동작함

elasticsearch.yml

node.master: true
node.data: false
node.ingest: false
search.remote.connect: false

Data Node

문서(= Document)가 실제로 저장되는 노드 = 데이터가 실제로 분산 저장되는 물리적공간인 샤드가 배치되는 노드

색인 작업에는 CPU, Memory, Storage 등 Computing Resource를 많이 소모하기 때문에 Resource 모니터링이 필요

데이터 노드는 가능하면 마스터 노드와 분리해서 구성하는게 좋음

설정 방법은 node.data를 true로 지정

Coordinating Node

Data Node, Master Node, Ingest Node의 역할을 수행하지 않고, 들어온 요청을 RR 방식으로 분산시켜주는 노드

(Round Robin : https://jwprogramming.tistory.com/17)

elasticsearch.yml

node.master:false
node.data: false
node.ingest: false
search.remote.connect: false

(모든 역할 off)

Ingest Node

색인 전 데이터를 전처리하기 위한 노드

데이터 포맷을 변경하기 위해 스크립트로 전처리 pipeline을 구성/실행 할 수 있음