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

springboot framework 을 이용해서 executable jar 구현 시 log4j2 사용 예)
- @Slf4j 사용
- logback.xml 사용
- -Dlogback.configurationFile=$DIR_HOME/logback.xml

로그가 중복으로 남을 경우)
- https://logging.apache.org/log4j/2.x/manual/configuration.html#Additivity
- <logger name="..." ... additivity="false" />
- 단순하게 보면, Logger 에 선언 된 appender 로 한번 기록하고 root logger 에 의해서 한번 기록 하게 되는 구조 입니다.

build.gradle 예)
configurations.all {
  exclude module: 'spring-boot-starter-logging'
}
...중략...
dependencies {
...중략...
  compile group: 'org.slf4j', name: 'slf4j-api', version: "${props.getProperty('slf4j')}"
  compile group: 'org.apache.logging.log4j', name: 'log4j-core', version: "${props.getProperty('log4j')}"
  compile group: 'ch.qos.logback', name: 'logback-classic', version: "${props.getProperty('logback')}"
  compile group: 'ch.qos.logback', name: 'logback-core', version: "${props.getProperty('logback')}"
...중략...
}

아래 주소에서 설치할 버전 선택 후 다운로드 받아서 설치 하셔도 됩니다.

Early Access

https://download.java.net/java/early_access/jdk18/7/GPL/openjdk-18-ea+7_linux-x64_bin.tar.gz

GA

https://jdk.java.net/archive/

AdoptOpenJDK

https://adoptopenjdk.net/release_notes.html

https://adoptopenjdk.net/archive.html?variant=openjdk8&jvmVariant=hotspot 

#!/bin/bash

retry='retry'

if [ $retry = "retry" ]; then
  echo 'true - 1'
fi

if [[ $retry = "retry" ]]; then
  echo 'true - 2'
fi

if [[ "$retry" = "retry" ]]; then
  echo 'true - 3'
fi

세 예제 다 true 리턴 합니다.

빌드 환경과 맞춰서 사용 하셔야 합니다.

안그러면 아래와 같은 에러를 경험 할 수 있습니다.

Exception in thread "main" java.lang.UnsupportedClassVersionError: com/zaxxer/hikari/HikariConfig has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Artifacts
Java 11+ maven artifact:

<dependency>
   <groupId>com.zaxxer</groupId>
   <artifactId>HikariCP</artifactId>
   <version>5.0.0</version>
</dependency>
Java 8 maven artifact (maintenance mode):

<dependency>
   <groupId>com.zaxxer</groupId>
   <artifactId>HikariCP</artifactId>
   <version>4.0.3</version>
</dependency>
Java 7 maven artifact (maintenance mode):

<dependency>
   <groupId>com.zaxxer</groupId>
   <artifactId>HikariCP-java7</artifactId>
   <version>2.4.13</version>
</dependency>
Java 6 maven artifact (maintenance mode):

<dependency>
   <groupId>com.zaxxer</groupId>
   <artifactId>HikariCP-java6</artifactId>
   <version>2.3.13</version>
</dependency>