jjeong

아마 사용하고 계시는 분들이 있을지 모르겠지만 간혹 Elastic Stack tarball 다운로드 받고 나서 파일이 깨지는 현상을 경험 하실 수 있는데요.

이럴 경우 다운로드 받은 tarball 이 유효 한지 확인 하는 방법을 소개 하려고 합니다. (이미 다 아실 만한 내용입니다.)

Elasticsearch 기준으로 설명 하겠습니다.

다운로드 페이지)

https://www.elastic.co/kr/downloads/elasticsearch

여기서 tar.gz 과 tar.gz.sha512 두 개의 파일을 다운로드 받습니다.

이제 checksum 검증을 하시면 됩니다. (아래는 mac 기준입니다.)

$ cat elasticsearch-8.3.2-darwin-x86_64.tar.gz.sha512
a8661896ba48365b6339d809c16f6c01a271ed76bbba4be10de08ade382ae6740968f9eb1f22ec1c30
fcca6aaf33d645530c3afb528ac20f3b638445c646d768  elasticsearch-8.3.2-darwin-x86_64.tar.gz

$ shasum -a 512 elasticsearch-8.3.2-darwin-x86_64.tar.gz
a8661896ba48365b6339d809c16f6c01a271ed76bbba4be10de08ade382ae6740968f9eb1f22ec1c30
fcca6aaf33d645530c3afb528ac20f3b638445c646d768  elasticsearch-8.3.2-darwin-x86_64.tar.gz

보시는 것 처럼 hash code 값이 같다면 다운로드 받은 tarball 이 유효 하다는 의미 입니다.

이와 같이 Elastic Stack 의 tarball 에 대한 검증 이후 사용 하시면 간혹 segment fault 오류에 대한 해결책이 될 수 있습니다.

Elasticsearch 8.3.2 + Lucene 9.2.0 에서 변경된 내용을 정리해 봅니다.

Lucene 8.11 to 9.2)

pom.xml 내 수정

# lucene-analyzers-common 은 9.x 에서는 더 이상 지원 하지 않음
<dependency>
  <groupId>org.apache.lucene</groupId>
  <artifactId>lucene-analyzers-common</artifactId>
  <version>${lucene.version}</version>
</dependency>
to
<dependency>
  <groupId>org.apache.lucene</groupId>
  <artifactId>lucene-analysis-common</artifactId>
  <version>${lucene.version}</version>
</dependency>

package 변경

org.apache.lucene.analysis.util.TokenFilterFactory
to
org.apache.lucene.analysis.TokenFilterFactory

org.apache.lucene.analysis.standard.ClassicFilter
to
org.apache.lucene.analysis.classic.ClassicFilter

org.apache.lucene.analysis.util.TokenizerFactory
to
org.apache.lucene.analysis.TokenizerFactory

org.apache.lucene.analysis.util.TokenFilterFactory
to
org.apache.lucene.analysis.TokenFilterFactory

org.apache.lucene.analysis.util.TokenFilterFactory
to
org.apache.lucene.analysis.TokenFilterFactory

elasticsearch analyzer plugin)

# AbstractIndexAnalyzerProvider 에서 IndexSettings 제거됨

org.elasticsearch.client.node.NodeClient
to
org.elasticsearch.client.internal.node.NodeClient

JDK 수정

build 시 jdk 17 사용
$jenv local 17

<java.version>17</java.version> 수정

❖ lucene 에서는 analyzer 패키지 변경이 있었으며, elasticsearch 에서는 NodeClient 에 대한 패키지 변경이 있었습니다.

보통 Query 절에서 문서를 필터링 하고 Aggs 에서 집합/분석 질의를 하게 됩니다.

이 경우 성능적 잇점을 가져 가기 위해서는 보통 아래 두 가지 설정만 잘 사용 하면 됩니다.

1. Query 절은 Non-Scoring 질의를 사용하고

2. Size 파라미터 값을 0 으로 사용하고

그 이외는 기본적으로 Elasticsearch 에서  Cache 기능이 잘 동작 하기 때문에 크게 고민을 하지 않으셔도 어느 정도의 성능은 나온다고 보시면 됩니다.

Bucket Aggregation 중 Query 절에서 Filtering 하는 것과 같은 기능이 있어서 문서 링크와 주의 사항(?) 올려 봅니다.

아래 두 질의는 같은 결과를 리턴 합니다.

Case 1)

POST /sales/_search?size=0&filter_path=aggregations
{
  "query": { "term": { "type": "t-shirt" } },
  "aggs": {
    "avg_price": { "avg": { "field": "price" } }
  }
}

Case 2)

POST /sales/_search?size=0&filter_path=aggregations
{
  "aggs": {
    "t_shirts": {
      "filter": { "term": { "type": "t-shirt" } },
      "aggs": {
        "avg_price": { "avg": { "field": "price" } }
      }
    }
  }
}

여기서 C1, C2 중 어떤게 좀 더 성능적으로 우세 할까요?

공홈 문서에 따르면 Sub Aggregation. 을 가지는 Filter Aggregation 보다는 Top Level Query 를 사용하는게 더 빠르다고 합니다.

그리고 다수의 Filter Aggregation 을 사용 하는 것 보다는 Filters Aggregation 을 사용 하는게 더 빠르다고 하니 참고 해서 사용 하시기 바랍니다.

제가 사용 한다고 하면 Top Level Query 에 Filter Query 나 Non-Scoring Query 를 이용해서 사용 할 것 같습니다.

공식 문서)

https://www.elastic.co/guide/en/elasticsearch/reference/current/common-options.html

Response Filtering)

https://www.elastic.co/guide/en/elasticsearch/reference/current/common-options.html#common-options-response-filtering

_search REST API 사용 시 유용하게 활용이 가능 합니다.

잘 응용해서 사용하세요.

결과 내 JSON Result 에서 filter_path 를 통해서 필요한 결과를 parsing 할 수 있습니다.

Aggregation 기능을 이용해서 Text 분석을 하고 싶을 때가 있습니다.

X-pack basic 범위에서 가능 하면 더 좋겠죠.

아래 공홈 문서 보시고 참고해 보시면 좋을 것 같습니다.

 - Text Analysis
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-categorize-text-aggregation.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-multi-terms-aggregation.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-rare-terms-aggregation.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-significantterms-aggregation.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-significanttext-aggregation.html

- Aggs Performance
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-filter-aggregation.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-filters-aggregation.html

사용하다 보면 정말 별거 아닌 건데 눈에 잘 안보일 때가 있습니다.

에러 메시지)

"reason"=>"failed to parse field [message] of type [text] in document with id '3UI29IEBerapX-zaQi4L'. 
Preview of field's value: 
...중략...
"caused_by"=>{"type"=>"illegal_state_exception", "reason"=>"Can't get text on a 
START_OBJECT at 1:529"}

이런 에러메시지를 접하게 되면 두 눈 크게 뜨고 Template 에서 정의한 type 정보와 실제 들어 오는 값이 잘 매핑이 되어 있는지 확인을 해보시기 바랍니다.

모니터는 큰걸로 글자 크기는 크게 해서 보세요. 

8.2.x 까지는 elasticsearch 에 대한 upgrade 를 위해서 symlink 를 이용해서 설치를 했었는데요.

물론 8.3.x 에서도 symlink 를 이용 합니다.

다만, 바뀐 부분이 있기 때문에 사전에 인지 하고 사용 하시면 좋습니다.

아래 파일을 열어 보시면 

$ vi bin/elasticsearch-env 

...중략...

# now make ES_HOME absolute
ES_HOME=`cd "$ES_HOME"; pwd`

...중략...

이와 같이 추가된 코드를 볼 수 있습니다.

그래서 elasticsearch 를 실행해 보면 이전에 symlink 정보로 표시 되던게 이제는 absolute path 로 바뀌어서 표시 되는 걸 ps 로 확인해 보실 수 있습니다.

Process 점검 할 때 실수 할 수 있는 부분 이니 알고 넘어 갑시다.