jjeong

오늘 삽질한 내용이라 짧게 일단 기록 부터 합니다.

설정이 특정 노드 한대에서 누락되어 있어서 삽질 했습니다.

이게 빠지게 되면 그냥 127.0.0.1 로 올라오기 때문에 정상적으로 binding 이 되지 않아 request 보내도 fail이 납니다.

아마도 elasticsearch 2.x 버전대 부터 지원 안하는 것 같습니다.

이걸 왜 된다고 생각하고 있었을까요??

혹시라도 사용하시는 분들은 CONF_PATH 로 변경해서 사용하시기 바랍니다.

# CONF_FILE setting was removed
if [ ! -z "$CONF_FILE" ]; then
    echo "CONF_FILE setting is no longer supported. elasticsearch.yml must be placed 
in the config directory and cannot be renamed."
    exit 1
fi

그냥 재미로 한번 매칭해 봤습니다.

크게 의미는 없으니 재미로 봐주세요.

Kafka)

Elastic Stack)

저는 이해하기 쉬운데 저만 그런가요??

아는 것도 이제는 기억이 가물가물 합니다. 그래서 또 기록해 봅니다.

사내 교육을 하면서 lucene 기본 이론 교육을 하다, start offset 과 end offset 에 대해서 설명을 해주고 있었는데요.

end offset 이 실제 text의 offset 값 보다 1 크다는 것에 대한 질문이 있었습니다.

아는 건데 일단 가볍게라도 설명하고 넘어 가야해서 아무래도 highlight 기능을 위해서 그렇게 설정 하는것 같다고 하고 오늘 문서랑 소스 코드 좀 다시 살펴 봤습니다.

lucene in aciton 에서 퍼온 글)

end offset 이 실제 보다 1 큰 이유는 문서에 있습니다.

그런데 왜 이렇게 되었을까를 고민해 보면 내부 처리 방식을  확인해 봐야 합니다.

highlight 기능이기 때문에 이 작업에 필요한 class 파일과 fragment에 대한 처리 로직을 확인 하면 됩니다.

protected String makeFragment( StringBuilder buffer, int[] index, Field[] values, WeightedFragInfo fragInfo,
    String[] preTags, String[] postTags, Encoder encoder ){
  StringBuilder fragment = new StringBuilder();
  final int s = fragInfo.getStartOffset();
  int[] modifiedStartOffset = { s };
  String src = getFragmentSourceMSO( buffer, index, values, s, fragInfo.getEndOffset(), modifiedStartOffset );
  int srcIndex = 0;
  for( SubInfo subInfo : fragInfo.getSubInfos() ){
    for( Toffs to : subInfo.getTermsOffsets() ){
      fragment
        .append( encoder.encodeText( src.substring( srcIndex, to.getStartOffset() - modifiedStartOffset[0] ) ) )
        .append( getPreTag( preTags, subInfo.getSeqnum() ) )
        .append( encoder.encodeText( src.substring( to.getStartOffset() - modifiedStartOffset[0],
          to.getEndOffset() - modifiedStartOffset[0] ) ) )
        .append( getPostTag( postTags, subInfo.getSeqnum() ) );
      srcIndex = to.getEndOffset() - modifiedStartOffset[0];
    }
  }
  fragment.append( encoder.encodeText( src.substring( srcIndex ) ) );
  return fragment.toString();
}

코드 보시면 아시겠죠.

기본적으로 String.substring( inclusive begin index, exclusive end index) 을 이용하기 때문에 end offset 값은 1 커야 하는 것입니다.

다른 의미로 보면 그냥 offset 정보와 text 의 length 정보를 한꺼번에 offsets 로 해결하기 좋은 방법으로 봐도 될 것 같습니다.

Timeout 소개라기 보다 하도 예전에 봤던거라 다시 한번 살펴 봤습니다.

2013년도에 0.90 버전때 봤던 코드라 2.2.0 기반으로 정리해 봅니다.

참고링크) 

원문 Snippet)

참고 클래스)

예전과 크게 달라 지지는 않았습니다.

첫번째 Timeout은 Shard 별 Search operation 에 대한 timeout 입니다. 

아시는 바와 같이 search request 를 보내게 되면 각 shard 수 만큼 thread 가 action 수행을 하게 됩니다. 이때 개별 thread 에 대한 timeout 설정이라고 보시면 됩니다.

두번째 Timeout은 search coordinator node에서의 timeout 입니다. 즉, 모든 shard 에서 데이터를 받을 때 까지의 timeout 이라고 보시면 됩니다.

거의 매주 올려 주는 elasticsearch & lucene 소식 입니다.

그냥 학습 한다 생각하고 요점 정리만 해볼 생각 입니다.

원문링크)

원문요약) 

올라온 것 중 개인적으로 keep 할 것만 추렸습니다.

Changes in master:

Ongoing changes:

master에 반영된 내용 중 눈에 확 들어 오는건 string field내요. 이제 text와 keyword로 맵핑을 해야 할 것 같습니다.

이미 반영된건 자동으로 업그레이드 되지 않지만 신규로 생성하는건 자동으로 되내요.

그리고 deprecated 된 query들 이제 remove 되었내요. 혹시라도 계속 사용하셨다면 에러 조심 하세요.

변경중인것 중에는 field명에 dot 지원이랑 percolator query가 눈에 들어 오내요. API 방식에서 Query 방식으로 변경되면 더 편하고 유용하게 사용할 수 있겠습니다.

나중에 또 잊어 버릴까봐 기록합니다.

참고문서)

예시)

"index": {
  "analysis": {
    "analyzer": {
      "arirang_custom": {
        "type": "custom",
        "tokenizer": "arirang_tokenizer",
        "filter": ["lowercase", "trim", "arirang_filter"]
      },
      "arirang_custom_searcher": {
        "tokenizer": "arirang_tokenizer",
        "filter": ["lowercase", "trim", "arirang_filter", "meme_synonym"]
      }
    },
    "filter": {
      "meme_synonym": {
        "type": "synonym",
        "synonyms": [
          "henry,헨리,앙리"
        ]
      }
    }
  }
}

여기서 주의할 점 몇 가지만 기록 합니다.

그럼 1번에서 선언 하지 않는 다는 이야기는 뭘까요?

선언 하지 않으시면 그냥 custom 으로 만들어 줍니다.

못 믿으시는 분들을 위해 아래 소스코드 투척 합니다.

[AnalysisModule.java]

String typeName = analyzerSettings.get("type");
Class<? extends AnalyzerProvider> type;
if (typeName == null) {
    if (analyzerSettings.get("tokenizer") != null) {
        // custom analyzer, need to add it
        type = CustomAnalyzerProvider.class;
    } else {
        throw new IllegalArgumentException("Analyzer [" + analyzerName + "] must have a type associated with it");
    }
} else if (typeName.equals("custom")) {
    type = CustomAnalyzerProvider.class;
} else {
    type = analyzersBindings.analyzers.get(typeName);
    if (type == null) {
        throw new IllegalArgumentException("Unknown Analyzer type [" + typeName + "] for [" + analyzerName + "]");
    }
}

arirang 한글 형태소 분석기를 적용하고 사전 데이터를 업데이트 할 일들이 많이 생깁니다.

jar 안에 들어 있는 사전 데이터는 패키지 빌드 후 재배포하고 클러스터 재시작까지 해줘야 하는데요.

이런 과정 없이 사전 데이터만 외부에서 파일로 업데이트 및 관리하고 재시작 없이 바로 적용했으면 합니다.

기본적으로 이전 글에서 사전 데이터를 reload 하는 REST API를 구현해 두었습니다.

이 기능으로 일단 기능 구현은 완료가 된 것입니다.

이전 글 보기)

그럼 elasticsearch에서 어디에 사전 파일을 두고 관리를 해야 적용이 가능 할까요?

이전 글을 보시면 기본적으로 수명님이 만드신 arirang.morph 에서 classpath 내  org/apache/lucene/analysis/ko/dic 과 같이 생성 및 배치 시키시면 먼저 이 파일을 읽어 들이게 되어 있습니다.

이전 글 보기)

단, elasticsearch 실행 시 classpath 정보에 생성한 경로를 추가하지 않으시면 사전 파일들을 찾을 수 없으니 이점 유의 하시기 바랍니다.

elasticsearch classpath 설정)

elasticsearch에서 가이드 하는 것은 수정하지 마라 입니다. 하지만 수정 없이는 이를 활용할 수 없으니 이런건 수정해줘야 합니다.

이렇게 수정하신 후 재시작 하시고 직접 사전 정보 업데이트 후 reload api 를 이용해서 적용되는지 확인해 보시면 되겠습니다.

참고 정보 - 간단 요약)

사전 데이터는 어떻게 등록 할 수 있는지 궁금하신 분은 이전 글 참고하세요.

사전 데이터 등록 예제)

작업 하는 김에 버전 올렸습니다.

git branch)

"index": {
  "analysis": {
    "analyzer": {
      "arirang_custom": {
        "type": "arirang_analyzer",
        "tokenizer": "arirang_tokenizer",
        "filter": ["lowercase", "trim", "arirang_filter"]
      }
  }
}

사전 reload 방법)

- 클러스터 재시작 없이 사전 데이터 수정 후 리로드 잘 됩니다. 단, 이미 색인 된 문서들은 재색인 해야 합니다.

Mapping parameters 중에 index_options에 대해서 알아보겠습니다.

(이전에 정리한게 없어서 복습 차원에서 기록 합니다.)

원본문서)

원본 Snippet)

Analyzed string fields use positions as the default, and all other fields use docs as the default.

The text field will use the postings highlighter by default because offsets are indexed.

▶ 내용을 정리해 보면 이렇습니다.

index_options 는 기본 analyzed field에 대해서 구성 하는 것입니다. not_analyzed field는 아니라는 이야기죠.

그리고 이 옵션은 아래로 내려 갈수록 상위 옵션을 포함하게 됩니다.

docs는 말 그대로 document count만 색인 합니다.

freqs는 말 그대로 docs + term frequnce를 색인 합니다.

positions는 말 그대로 freqs + term position을 색인 합니다.

offsets는 말 그대로 positions + term offset을 색인 합니다.

positions를 설정 하게 되면 proximity 또는 phrase query를 사용 할 수 있습니다. 즉, 설정 하지 않으면 말짱 꽝!!

offsets를 설정 하게 되면 추가적으로 highlight 기능을 사용 할 수 있습니다. 강조를 사용해야 하는데 설정 하지 않으면 역시 말짱 꽝!!

analyzed field 의 기본 index_options는 positions 입니다. 그리고 강조 기능은 기본 posting hilighter 입니다.