jjeong

로컬에서 테스트 할 때 주의 해야 하는 점이 있습니다. 

같은 shard 가 같은 host 장비에 할당 되게 하려고 아래와 같은 설정을 합니다.

cluster.routing.allocation.same_shard.host: true

그런데 이 설정으로 인해서 shard allocation 적용 시 동작 하지 않게 됩니다.

사용 시 위 설정에 대해서 반드시 확인 하고 사용 하세요.

(같은 실수를 몇 번 하는 지 ㅡ.ㅡ;;)

코드만 봤을 때는 sum 보다 stats 가 느려야 하는게 정상으로 보입니다.

실제 문서의 구조와 질의를 어떻게 사용 했는지를 모르는 상황에서는 sum 보다 stats 가 빠르다는 부분에 대해서는 판단 하기가 어렵네요.

일단 sum, stats 와 같은 aggs 를 잘 사용하기 위해서는 아래 내용 정도 인지 하고 사용 하시면 좋을 것 같아 기록해 봅니다.

• field data 유형이 numeric, geopoint, range 그 이외 유형이거나 null 이 아니도록 처리 합니다.
• null 에 대한 처리를 위해 missing parameter 를 적용 합니다.
• if else 구조로 성능 이슈 있을 수 있습니다.

그냥 pull request 날렸습니다.

https://github.com/elastic/elasticsearch/pull/76400

그러나 Contributor Agreement 를 안했다고 하는데 이것 참.. 
했는데 왜 저게 나오는지 도대체 Docu Sign 을 몇 번을 했는지 모르겠네요 ㅡ.ㅡ;

코드를 확인해 보니 _forcemerge API 에는 특정 shard 만 지정 하는 기능은 없었습니다.

뭐 어떻게 보면 당연한 이야기지만, 그래도 _routing 을 사용 하면서 특정 shard 로 operation 이 집중되게 되면 해당 shard 의  segments 파일이 많이 생성 될 수도 있습니다.

그래서 코드를 좀 고쳤습니다.

contribute 을 위해 pull request 를 올려야 하는데 이 귀차니즘을 어찌 하죠.

암튼 별건 아니라서 일단 코드 부터 올려 놓습니다. 

분명 어딘가에 기록해 두었는데 이걸 왜 못찾고 있는 거지..ㅡ.ㅡ;

http://elastic:password@localhost:9200/test-index

elasticsearch 에서 기본 인증을 사용 할 경우 API token 사용 이런게 아니라면 단순하게는 저렇게 보낼 수 있습니다.

https://www.ietf.org/rfc/rfc2617.txt

공식 스펙은 위 문서 참고 하시면 됩니다. (Basic Authentication)

URL 로 보내기 싫으시면 header 로 보내시면 됩니다.

elastic:password 를 base64 인코딩 하시고 "Authorization" 헤더로 값을 보내시면 되겠습니다.

KEY : Authorization

VALUE : Basic ZWxhc3RpYzpwYXNzd29yZA==

Quick 하게 아래 처럼 일단 시작 부터 해봅시다.

[Elasticsearch Contribute]
https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md

소스코드 내려 받고 elasticsearch 7.14.0 빌드 및 실행
운영 환경에서 실행 시 jdk 11 로 가능 하지만 빌드 시는 jdk 16 을 요구 합니다.

% jenv local 16
% ./gradlew :run

공식 문서 참고)

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 하는 방법에서 제시 한 것과 어느 정도 부합 한다는 것을 볼 수 있습니다.

기억력을 돕기 위해서 기록 합니다.

참고 문서)

https://www.elastic.co/guide/en/elasticsearch/reference/master/mapping-settings-limit.html

index.mapping.field_name_length.limit)

Setting for the maximum length of a field name. 
This setting isn’t really something that addresses mappings explosion 
but might still be useful if you want to limit the field length. 
It usually shouldn’t be necessary to set this setting. 
The default is okay unless a user starts to add a huge number of fields with really long names.

Default is Long.MAX_VALUE (no limit).

mapping explosion 과 같은 경우에 유용 할 수 있다는 이야기 입니다.

기본은 노 제한!!

보너스로 그럼 Index 명은 얼마인가요?

- 255 bytes 입니다. (실제 멀티바이트 문자 이기 때문에 더 짧습니다.)

- https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html#indices-create-api-path-params

그냥 궁금해서 추가적으로 cluster.name 과 node.name 의 max length 는 어떻게 될까 찾아 봤는데요.

Java 의 Sting 클래스의 max length 라고 보시면 됩니다.

그러나 cluster.name 과 node.name 은 가독성이 중요 하기 때문에 저렇게 길게 작명 하는 나쁜 부모는 되지 말아야 겠죠.

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

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

예) 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"}