jjeong

아는 것도 시간이 지나면 다 까먹는 나이!!

[레퍼런스]

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-fields.html#_search_and_aggregation_scripts
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-expression.html

접근 유형에 따른 성능)

doc value 가 가장 빠르고 _source 와 _fields 는 비슷 합니다.

QueryDSL 예제)

GET /kibana_sample_data_ecommerce/_search
{
  "query": {
    "script_score": {
      "query": {
        "bool": {
          "filter": {
            "term": {
              "products.product_name": "shirt"
            }
          }
        }
      },
      "script": {
          "lang": "expression",
          "source": "_score * doc['taxless_total_price']"
        }
    }
  }
}

GET /kibana_sample_data_ecommerce/_search
{
  "query": {
    "script_score": {
      "query": {
        "bool": {
          "filter": {
            "term": {
              "products.product_name": "shirt"
            }
          }
        }
      },
      "script": {
          "lang": "painless",
          "source": "_score * doc['taxless_total_price'].value"
        }
    }
  }
}

GET /kibana_sample_data_ecommerce/_search
{
  "query": {
    "script_score": {
      "query": {
        "bool": {
          "filter": {
            "term": {
              "products.product_name": "shirt"
            }
          }
        }
      },
      "script": {
          "lang": "painless",
          "source": "_score * params._source.taxless_total_price"
        }
    }
  }
}

expression 과 painless 에 따라 다르기 때문에 사용에 주의 하세요.

Elastic Stack 에서 Date Field Type 사용 시 내용을 인지 하고 사용 하셔야 데이터에 대해서 기대한 결과를 얻을 수 있습니다.

우선, Elasticsearch 는 기본 UTC 시간을 사용 합니다.

색인 되는 Date 값은 모두 UTC 로 저장 된다고 보시면 됩니다.

또한 기본 질의 시 사용 하는 값도 UTC 입니다.

하지만, Kibana 를 사용 하다 보면 UTC 에 대한 사용이 불편해서 브라우저 TZ 설정이나 사용자 정의 TZ 설정으로 Date 값을 사용 할 때가 있습니다.

이때 주의 해야 할 점은 실제 색인된 데이터에 대한 변형이나 조작이 있는게 아닌 Client 단에서 TZ 설정에 따른 질의 시 Date 값 변환이나 화면에서의 조작을 한다는 것을 알아야 합니다.

아래 설명은 그냥 저 혼자 기억하기 위해서 풀어 쓴걸 올려 둔 내용 입니다.

- kibana 에서는 실제 색인된 date 유형의 값에 대한 tz 설정으로 화면에서 변환 된 정보로 보여 주는 것이며,
실제 질의는 utc 데이터로 질의가 이루어 집니다.
  ㄴ 결국 query dsl 작성 시 utc 기준으로 작성이 되어야 하기 때문에
     본인이 속한 tz 값을 계산 해서 질의 값에 반영이 되어야 합니다.
  ㄴ 단순 tz 설정만 하고 현재 속한 tz 값 기준으로 질의를 작성 하게 되면
     KST 기준으로는 미래에 대한 datetime 값으로 질의를 하게 되어 데이터가 존재 하지 않을 수 있습니다.

  QueryDSL UTC 값 변환을 위한 TZ 설정과 값은 아래와 같이 해야 동작 합니다.
    KST 기준으로 오전 11시 보다 큰 값으로 질의 하고자 할 때 Elasticsearch 는 UTC 기준으로
    오전 2시 보다 큰 값으로 질의가 되어야 합니다.
      "time_zone": "+09:00",
      "gte": "2022-11-18T11:00:00.000"
      to
      "gte": "2022-11-18T02:00:00.000"
    와 같이 실제 Elasticsearch 에 저장 되는 UTC 값으로 변환 되어 질의하게 됩니다.
    아래와 같이 설정 되면 동작 하지 않습니다.
      "time_zone": "+09:00",
      "gte": "2022-11-18T11:00:00.000Z"
    Z 가 들어 가게 되면 TZ 설정이 적용 무시 되고 값 자체를 UTC 값으로 질의 하게 됩니다.

Z 는 java.time 아래 클래스 관련 설명이 되어 있습니다. (소스코드 참고하세요.)

용도와 목적에 맞게 선택해서 사용 하면 될 것 같습니다.

1. Date Histogram

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-datehistogram-aggregation.html

2. Count API

https://www.elastic.co/guide/en/elasticsearch/reference/8.5/cat-count.html

https://www.elastic.co/guide/en/elasticsearch/reference/8.5/search-count.html

3. Stats API

https://www.elastic.co/guide/en/elasticsearch/reference/8.5/indices-stats.html

문서 수가 가끔 필요할 때가 있습니다.

제공 하는 API 를 활용해서 목적에 맞게 사용 하면 될 것 같습니다.

공홈 레퍼런스 문서)

https://www.elastic.co/guide/en/elasticsearch/reference/8.5/term-level-queries.html

https://www.elastic.co/guide/en/elasticsearch/reference/8.5/normalizer.html

한 줄 요약)

Keyword field 의 경우 normalizer 선언을 할 경우 index analyzer 뿐만 아니라 search analyzer 에도 동일하게 적용 됩니다.

보통 Keyword field 사용 시 term level query 를 사용하게 되면 검색어에 대한 형태소 분석 없이 token 에 대한 exact matching 을 한다고 가정 하게 됩니다.

이 경우에 해당 하기 위해서는 keyword field 선언 시 normalizer 선언이 없어야 적용이 됩니다.

아래는 관련 코드에 대해서 일부 snippet 한 내용입니다.

NamedAnalyzer normalizer = Lucene.KEYWORD_ANALYZER;
NamedAnalyzer searchAnalyzer = Lucene.KEYWORD_ANALYZER;
NamedAnalyzer quoteAnalyzer = Lucene.KEYWORD_ANALYZER;
String normalizerName = this.normalizer.getValue();

KeywordFieldMapper 클래스에 선언된 코드 입니다.

보시면 기본 Search Analyzer 는 Keyword Analyzer 입니다.

...중략...
searchAnalyzer = quoteAnalyzer = normalizer;
...중략...

코드 중간에 들어가 보면 이와 같이 선언 된 것을 보실 수 있습니다.

그리고 노말라이저 선언이 없으면 

searchAnalyzer = Lucene.WHITESPACE_ANALYZER;

Whitespace Analyzer 로 선언 되는 것도 확인이 가능 합니다.

보시면 아시겠지만 기본적으로 Keyword type 에 선언 되는 Search Analyzer 는 Lucene.KEYWORD_ANALYZER 로 선언 되게 되어 있습니다.
즉, Normalizer 선언이 없으면 기본이 키워드 인거죠. 그래서 별도 형태소 분석 과정이 없다보 인식 하는 건데 사실 없다고 보기 어렵고 Keyword Analyzer 의 Token Filter 를 따른다고 이해 하는게 맞습니다.

https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-keyword-analyzer.html
이 분석기는 아무런 선언을 하지 않으면 noop 에  정확히 텍스트가 일치해야 하는 분석기 입니다.
근데 색인 시점에 whitespace 를 포함한 텍스트를 keyword 로 선언 하고 이걸 whitespace 로 토큰 분해 하고 싶을 경우 "split_queries_on_whitespace" 이 옵션을 true 로 해주시면 됩니다.

그럼 KeywordAnalyzer/Tokenizer 이넘의 기본 형태소 분석은 그냥 텍스트를 하나의 토큰으로 분석 한다고 이해 하시면 되겠습니다.
여기서 whitespace 단위로 분해하고 싶으면 바로 위에 옵션 활용, 그리고 normalizer 는 토큰에 적용 되는데 search analyzer 에 반영 된다는 걸 기억 하면 됩니다.
문서에 나와 있던 내용 그대로 이고요. 코드 상으로는 어떻게 되어 있을까 궁금해서 찾아본 내용 공유 드립니다. ^^

보셔야 하는 클래스는

• KeyowrdFieldMapper
• KeywordAnalyzer
• KeywordTokenizer

jenkins pipeline job 을 생성하고 groovy 스크립트 내부에서 일반 shell script 를 사용 할 때가 있습니다.

보통 아래와 같이 많이 사용 하는데요.

sh '''
echo "Hello World!"
'''

bash 를 지정해서 사용 하고자 할 때는 아래와 같이 적용을 해줘야 합니다.

sh '''#!/bin/bash
echo "Hello Bash!!"
'''

여기서 사용 시 주의사항은 #!/bin/bash 를 ''' 에 붙혀서 작성을 해줘야 합니다.