jjeong

공식 문서 참고)

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html

API)

POST /my-index-000001/_forcemerge

force merge 는 너무 많이 생성된 Segments 파일을 병합 하거나 삭제 된 문서를 물리적으로 병합 하면서 제거 하거나 하는 작업을 수행 하게 됩니다.

보통은 merge policy 에 의해서 자동으로 수행이 되긴 하지만 간혹 수동으로 실행을 해야 할 때도 발생을 합니다.

그럼 Segments 파일을 어느 정도 수준으로 유지 하는게 좋을까요?

그 전에 확인할 사항이 있습니다.

1. Segment 파일에 문서 수가 많나요?

2. Segment 파일에 문서의 크기가 큰 것일까요?

결국 이 Segments 파일은 IndexWriter 즉, 색인 보다는 검색에 영향을 많이 주는 요소라고 보면 됩니다.

짧은 용량의 Segments 파일이 많이 있다고 가정 하면 파일 수 만큼의 IndexeReader 가 준비 되어야 하고 그에 맞는 thread 가 일을 해야 하기 때문에 다소 성능이 떨어 질 수도 있습니다.

반대로, 용량이 큰 Segments 파일이 있다고 하면 Single thread 로 동작 하기 때문에 역시 성능이 떨어 질 수 있기도 합니다.

그래서 가장 최적의 Segment file 의 크기와 수를 구해야 검색 성능을 확보 할 수 있습니다.

보통은 Primary shard 와 Replica shard 를 가지고 접근을 하게 됩니다. 그러다 Node 수준까지 접근 하게 되고 더 나아가 Application 수준까지 ...

Segment 파일이 가질 수 있는

- 최대 문서의 수는 Integer.MAX_VALUE (2,147,483,519) 만큼 가질 수 있습니다.

- 문서 하나의 최대 크기는 2GB 입니다.

제가 제안 하는 범용적인 Segment 파일은

- 최대 문서 수는 1천만 ~ 5천만

- Segment file 크기는 2GB ~ 5GB

- Segment file 수는 Core 크기와 같거나 1/2 만큼

정도 인것 같습니다.

Segment 는 Lucene 기준으로 검토를 하셔야 하고 Elasticsearch 기준으로 확장 한다고 하면 Shard 까지 검토를 하셔야 합니다.

제가 제안한 정보를 기준으로 단순 예를 들어 보면)

- 코어가 10개 라고 하고

- 1/2 만큼의 Segments file : 5개

- Shard 1개의 크기는 5 개 Segments file x 2GB : 10GB

대략 Node와 Shard size estimation 하는 방법에서 제시 한 것과 어느 정도 부합 한다는 것을 볼 수 있습니다.

그냥 작은 운영 팁 정도 입니다.

영어+한글로 작성된 경우 둘 다 사전에 등록 되어 있지 않다고 하면 아래와 같이 등록을 하면 됩니다.

예) kr모터스

extension.dic 에 한글 "모터스" 만 등록 합니다.

모터스,100000000X

POST http://localhost:10800/_analyze

Request)

{

"tokenizer": "arirang_tokenizer",

"filter": [

"arirang_filter"

],

"text": "kr모터스"

}

Response)

{

"tokens": [

{

"token": "kr모터스",

"start_offset": 0,

"end_offset": 5,

"type": "korean",

"position": 0

},

{

"token": "kr",

"start_offset": 0,

"end_offset": 2,

"type": "word",

"position": 0

},

{

"token": "모터스",

"start_offset": 2,

"end_offset": 5,

"type": "korean",

"position": 1

}

]

}

분명 어딘가에 기록해 두었던 것 같은데 또 못찾고 있다.

그래서 손꾸락이 기억 하라고 작성해 봅니다.

- Elasticsearch start
#!/bin/bash

DIR_NAME=`dirname "$0"`
DIR_HOME=`cd $DIR_NAME; cd ..; pwd`

ES_JAVA_OPTS="-Xms512m -Xmx512m" $DIR_HOME/bin/elasticsearch -d -p $DIR_HOME/PID

- Elasticsearch stop
#!/bin/bash

DIR_NAME=`dirname "$0"`
DIR_HOME=`cd $DIR_NAME; cd ..; pwd`

pkill -F  $DIR_HOME/PID

공홈 문서 보시면 됩니다.

https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html

워낙에 제가 예전에 작성해 놓은 글이 있어서 그냥 최신 버전으로 remind 합니다.

$ curl -s -H "Content-Type: application/x-ndjson" -XPOST http://localhost:9200/_bulk 
  --data-binary "@ATC.json"

ATC.json)

{"index": { "_index": "atc", "_id": "1"}}
{"chosung": "ㄴㅇㅋ", "chosung_eng": "nike", "jamo_kor": "ㄴㅏㅇㅣㅋㅣ", "jamo_eng": "skdlzl", "item_kor": "나이키", "item_eng": "nike"}

https://github.com/HowookJeong/elasticsearch-analysis-arirang/tree/hanguel-jamo-tokenizer-7.12.0

Checkout 받으신 후 빌드 하시고 설치 하시면 됩니다.

$ mvn clean install -DskipTests=true
$ bin/elasticsearch-plugin install file:///Users/mzc02-henryjeong/Works/github/howookjeong/elasticsearch-analysis-arirang/target/elasticsearch-analysis-arirang-7.12.0.zip

[Request]
curl --location --request POST 'http://localhost:9200/_arirang/jamo?text=엘라스틱서치&token=CHOSUNG'

[Method]

GET / POST

[Response]
CHOSUNG -> ㅇㄹㅅㅌㅅㅊ
JUNGSUNG -> ㅔㅏㅡㅣㅓㅣ
JONGSUNG -> ㄹㄱ
KORTOENG -> dpffktmxlrtjcl

[Parameters]

• text
  형태소 분석할 문자열
• token
  분석 유형 지정
  CHOSUNG (초성)
  JUNGSUNG (중성)
  JONGSUNG (종성)
  KORTOENG (한영 변환)

기능 테스트로 넣어 둔거라서 성능적인 검증은 하지 않았습니다.

https://github.com/elastic/rally
https://esrally.readthedocs.io/en/stable/

elasticsearch cluster 성능 점검용으로 활용 하면 좋아요.

Elastic 사에서 제공 하는 다양한 도구와 서비스 들이 있습니다.

APM 이라는 아주 좋은 도구도 제공 하는데요.

Quick 하게 필요한 정보만 기록해 봅니다.

[Elastic APM Server]

https://www.elastic.co/guide/en/apm/server/current/overview.html
https://www.elastic.co/downloads/apm

[Elastic APM Agent]

https://www.elastic.co/guide/en/apm/agent/java/current/intro.html
https://search.maven.org/search?q=g:co.elastic.apm%20AND%20a:elastic-apm-agent

<intellij 에서 vm 옵션으로 등록합니다.>
-javaagent:/Users/mzc02-henryjeong/Works/elastic/apm-agent/elastic-apm-agent-1.22.0.jar -Delastic.apm.service_name=poc-service -Delastic.apm.application_packages=com.mzc.poc -Delastic.apm.server_url=http://localhost:8200

<Kibana 에서 Index Pattern 등록 하고 Discover 합니다.>

apm-{versin}-onboarding-*
apm-{versin}-span-*
apm-{versin}-error-*
apm-{versin}-transaction-*
apm-{versin}-profile-*
apm-{versin}-metric-*

- alias 로 자동 생성 되어 있음.

구성 시 사전 필요한 stack 은)

- Elasticsearch

- Kibana

- Spring Boot Web Application

[Enable]
$ ./metricbeat modules enable apache mysql

[Disable]
$ ./metricbeat modules disable apache mysql

App Search 에서 JSON Document 색인을 하려다 보니, 에러가 발생을 해서 기록해 둡니다.

Elasticsearch 에서는 문제가 안되는 부분 입니다.

Field 명 작성 시 주의 사항)

- lowercase 로 작성이 되어야 합니다.

처음 부터 문서 설계 시 lowercase 로 설계 하시기 바랍니다.

이미 대소문자가 섞여 있는 것들에 대한 추가 작업이 필요 한데 왜 안쓰는지 알겠네요.

업무 협업 도구들이 많이 나오면서 생산 되는 정보와 문서에 대한 검색 Needs 가 생기는 건 자연 스러운 현상이라고 생각 합니다.

개인적으로는 대부분 오픈소스를 이용해서 개발 환경을 구성하고 사용을 하고 있다 보니 비용이 발생 하는 도구를 선택 하기가 쉽지 않은 건 또 다른 현실 인것 같습니다.

https://www.elastic.co/guide/en/workplace-search/current/workplace-search-install.html

Elastic 사에서 무료로 제공 하고 있는 Workplace Search 라는 것이 있습니다.

Enterprise Search 에서 제공 하는 서비스 입니다.

저는 개인적으로 Slack 에 대한 사용을 해보고 싶어서 구성해서 테스트를 진행하려 했는데요.

ㅠ.ㅠ

Slack 하필 Content Sources 중 현재 유료 버전에 속한 것중 하나 더라구요.

그냥 이거 무료로 풀어 주시면 참 좋을 텐데 말입니다.

Workplace Search 에서 무료로 추가해서 사용 할 수 있으면 너무 편하겠지만 이게 안된다고 하면,

그냥 Slack API 를 이용해서 메시지를 가져와 Elasticsearch 로 직접 색인 하는 방법으로 진행 하면 되긴 합니다.

어차피 Enterprise Search 에서 Workplace Search 라는 게 독립적으로 동작 하는 방식이 아닌

    Slack <---> Workplace Search Slack Content Source 등록 <---> Elasticsearch

와 같이 동작 하니까 말이죠.

그럼에도 불구하고 Slack, Gmail 을 제외 하고 나머지는 무료 이니 필요 하신 분들은 잘 활용 하시면 업무에 도움이 되지 않을까 생각 합니다.