'ITWeb/검색일반'에 해당되는 글 23건

  1. 2017.11.14 [Lucene] Inverted index file - 역인덱스 파일
  2. 2017.10.25 [Lucene] QueryString Parser 간단 살펴보기
  3. 2017.07.31 [Lucene] SynonymFilter -> SynonymGraphFilter + FlattenGraphFilter
  4. 2017.07.25 [Arirang] compounds.dic 사전
  5. 2017.07.17 [esquery-proxy] Elasticsearch 용 RESTful API Gateway/Proxy
  6. 2017.06.23 [Arirang] 사전 기반으로만 형태소 분석 처리 해보기
  7. 2017.06.09 [Arirang Analyzer - lucene 6.5.0] Term startOffset 정렬 오류
  8. 2017.06.09 [Arirang] first position increment must be > 0 오류
  9. 2017.05.31 [검색] SEO 태그 가이드
  10. 2017.01.19 [Lucene] Multi-value fields and the inverted index

[Lucene] Inverted index file - 역인덱스 파일

ITWeb/검색일반 2017.11.14 23:15

루씬에서 검색을 하기 위해 필요한 파일을 살짝 알아보겠습니다.

파일 구조와 목록은 아래 문서를 참고 하시기 바랍니다.

Lucene Index File Formats)

https://lucene.apache.org/core/7_1_0/core/org/apache/lucene/codecs/lucene70/package-summary.html#package.description


그럼 실제 검색을 위해 보셔야 하는 기본이 되는 클래스는 

  • IndexSearcher
  • IndexReader
  • CollectionStatistics
  • TermStatistics

이렇게 4개 정도 보시면 될 것 같습니다.


검색을 위해 필요한 정보는

  • Documents
  • Fields
  • Terms
  • FieldInvertState

이렇게 4개 정도가 필요 합니다.

딱 봐도 "searchField:elasticsearch" 하면 

  • searchField 라는 field 정보가 필요하고, 
  • elasticsearch 라는 term 관련 정보도 필요하고, 
  • elasticsearch 라는 term 이 있는 document 정보도 필요하고,
  • 해당 field 에서의 term 이 추출 된 offset과 position 정보가

필요합니다.


이걸 정리한 이유는 오늘 누가 custom function score query 를 사용하여 다수의 field 에 대한 ranking term boosting 기능을 사용하고 있는데 성능적으로 개선 할 수 있는 방법이 없는지 물어봐서 간단하게 정리해봤습니다.

Query 튜닝은 한계가 반드시 존재 합니다.

서버의 구조적인 개선과 튜닝을 병행해야 하며 다수의 field 에 대한 다수의 term boosting 은 최적화를 통해 최소화 해서 사용하는걸 추천 드립니다.

그리고 inverted index file 이라는 것은 루씬에서 하나의 파일만 이야기 하는 것이 아니라 lucene 이 가지고 있는 index file 목록들이 inverted index file 을 구성 한다고 보시면 될 것 같습니다.

저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

[Lucene] QueryString Parser 간단 살펴보기

ITWeb/검색일반 2017.10.25 13:11

초간단 기억용으로 막 작성했습니다.


[QueryString Parser]

() - group

(jakarta OR apache) AND website

field:() - field group

title:(+return +"pink panther")

{} - range query - exclusive

[] - range query - inclusive

"" - exact term (non_analyzed)

field:something somthing - match query (analyzed)

? - single character

* - 0 or more chracters

~ - levenshtein distance query (fuzzy query)

""~10 - slop position gap within 10 words (proximity query)

something - boolean query

+something - must have something

-something - must not have something

^ - boosting

OR operator OR or ||

AND operator AND, && or +

NOT operator NOT, ! or -


dismax query parser

https://lucene.apache.org/solr/guide/6_6/the-dismax-query-parser.html

저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

[Lucene] SynonymFilter -> SynonymGraphFilter + FlattenGraphFilter

ITWeb/검색일반 2017.07.31 18:37

오늘 뭐 좀 보다가 그냥 공유해 봅니다.
https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-synonym-tokenfilter.html


lucene 6.6 에서는 SynonymFilter@Deprecated 되어 있습니다.

대체 filter 는 글에도 나와 있지만 SynonymGraphFilter 인데요.

재밌는건 이넘은 search time 에서 동작 하는 거라 index time 에는 여전히 SynonymFilter 또는 FlattenGraphFilter 를 사용해야 한다는 점입니다.

아직 깊게 분석해보지 않아서 ^^; 


간만에 lucene 코드 까서 이것 저것 테스트 해보니 재밌내요.

그냥 참고 하시라고 올려봤습니다.


저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

[Arirang] compounds.dic 사전

ITWeb/검색일반 2017.07.25 12:16

또 기억이 나지 않아 기록 합니다.


arirang 에서 많이 사용하는 사전중에 복합명사 사전이 있습니다.

compounds.dic 이라는 사전 인데요.


구조는 이렇습니다.

분해전단어:분해후단어1,분해후단어2,...,분해후단어N:DBXX

분해전단어에 하여(다)동사, 되어(다)동사 가 붙을 수 있는지 확인 하셔야 합니다.


예)

객관화:객관,화:1100


이와 같이 된 이유는

객관화하다

객관화되다

가 되기 때문입니다.


참고)

http://krdic.naver.com/search.nhn?query=%EA%B0%9D%EA%B4%80%ED%99%94&kind=all


저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

[esquery-proxy] Elasticsearch 용 RESTful API Gateway/Proxy

ITWeb/검색일반 2017.07.17 19:01

Elasticsearch 를 서비스 용도로 많은 분들이 사용하고 계시는 것으로 압니다.

저 처럼 Java API를 사용하고 계신 분들도 계실 테고 RESTful API 를 사용하고 계신 분들도 계실 것으로 압니다.

그냥 버전 업그레이도 해야 하고 해서 재미 삼아 가볍게 만들어 보았습니다.

관련해서 

- 단순 기능 동작 유무만 확인했습니다. (잘 됩니다.)

- 성능 테스트 하지 않았습니다.

- 안정성 테스트 하지 않았습니다.

그래서 가져다 막 고쳐서 사용하시면 좋겠습니다. 


일단 만들게 된 동기는

- Search 와 Aggregation 에 대해서 사용할 목적으로 만들었습니다.

- Elasticsearch JAVA API 버전 관리에 대한 유지보수 비용을 절감 해야 했습니다.

- Elasticsearch Cluster 에 대한 Version Upgrade 도 수행 해야 했습니다.

- Multi Cluster 에 대한 Concurrent 처리가 가능 해야 했습니다.


프로젝트 코드를 보시면 아시겠지만 매우 간단 합니다.


사용한 Framework)

- SpringMVC + Maven Project

- pom.xml  내 dependency 참고 하시면 됩니다.


지원 가능한 API)

- Elasticsearch에서 제공하는 거의 모든 RESTful API 를 제공 합니다.

- HTTP POST 만 구현해 놨기 때문에 POST 를 지원하지 않는 API 는 동작 하지 않습니다.

- 조만간 시간 나는데로 추가해 보겠습니다.

- Single Request 뿐만 아니라 Multi Request 도 지원 합니다.

- Single Cluster 뿐만 아니라 Multi Cluster 로 Request 를 보낼 수 있습니다.

-  서로 다른 Version 의 Cluster 라도 상관 없습니다.


Single Request Example)

[WAS Endpoint]

http://localhost:8080/query


[Method]

POST RAW


[Request Body]

{

  "target":"http://{YOUR-CLUSTER}/{YOUR-INDEX}/_search",

  "query":{}

}

- target

-  요청할 Elasticsearch Cluster 의 RESTful Endpoint 를 작성 하시면 됩니다.

- {YOUR-INDEX} 는 alias, single index, multi index  모두 사용 가능 합니다.

- query

- 기존에 사용하시던 QueryDSL 문을 그대로 넣어 주시면 됩니다.

- match_all  query 가 실행 됩니다.


Multi Request Example)

[WAS Endpoint]

http://localhost:8080/mquery


[Method]

POST RAW


[Request Body]

[

{

  "target":"http://{YOUR-CLUSTER1}/{YOUR-INDEX1}/_search",

  "query":{}

},

{

  "target":"http://{YOUR-CLUSTER1}/{YOUR-INDEX2}/_search",

  "query":{}

},

{

  "target":"http://{YOUR-CLUSTER2}/{YOUR-INDEX1}/_search",

  "query":{}

},

{

  "target":"http://{YOUR-CLUSTER2}/{YOUR-INDEX2}/_search",

  "query":{}

}

]


 Multi Request 의 경우 _msearch API 와 비슷 하게 동작은 합니다.

다만, _msearch의 경우 서로 다른 클러스터간에 통신은 지원 하지 않습니다.



추가 Parameters)

- routing

이 기능은 특정 key 를 가지고 문서를 저장 하기 위한 대상 shard 를 지정 하기 위해 사용 합니다.

문서 저장 시 해당 key 에 대한 Grouping 이나 Classify 를 위해 사용 합니다.

자세한 내용은 Elastic 사의 Reference 문서를 참고하세요. (클릭)

- preference

이 기능은 검색 질의 시 아주 유용하게 활용이 가능 합니다.

특정 shard 를 지정 할 수도 있고 질의 하고 싶은 node 를 선택 할 수도 있습니다.

자세한 내용은 Elastic 사의 Reference 문서를 참고하세요. (클릭)


Github Repository)

https://github.com/HowookJeong/esquery-proxy

저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

[Arirang] 사전 기반으로만 형태소 분석 처리 해보기

ITWeb/검색일반 2017.06.23 13:51

그냥 사전만 가지고 몇 가지 형태소 분석 처리를 하기 위한 팁 정보 입니다.

한마디로 노가다 입니다.

모든 부분에 공통적으로 적용 되는 것은 아니며 사용 형태에 따라 수정 하셔야 하는 부분이니 그냥 참고 정도만 하자라고 생각해 주세요.


공통)

- 복합명사 분해 시 분해 된 단어가 용언일 경우 복합명사를 사용하지 말고 확장사전에 등록해서 사용을 합니다.

  또는 분해 된 단어가 용언일 경우 찾아서 체언 처리를 해줍니다.

- 체언과 기타품사 차이는 체언은 단독으로 사용 시 형태소 분석이 되지만 기타품사는 분석 되지 않습니다.


  복합명사)

    그리는게:그리는,게:0000


  확장사전)

    그리,100000000X

    그리는게,100000000X


  분해)

    그리는게

      그리는게

    그리는

      그리


'그리는' 자체를 체언으로 분해 하고 싶을 경우 확장 사전에 체언으로 등록이 되어야 하며, 그리에 대한 용언도 동일하게 체언처리가 되어야 합니다.



- '~요', '~해요' 로 끝나는 용언 처리

  좋아요

  좋아해요


  확장사전)

    좋아,100000000X

    좋아해,100000000X



- '~져', '~져서', '~서' 로 끝나는 용언 처리

  기존 용언으로 등록된 단어를 체언으로 변경 해야 합니다.

  010000000X -> 100000000X

  '~서' 의 경우 사전에 '서,110000000X' 와 같이 등록이 되어 있어 복합명사 사전에 추가 등록을 합니다.

  복합명사 등록 시 분해된 명사에 대한 확장사전 등록이 되어 있어야 합니다.


  확장사전)

    어두워지,100000000X

    어두워,100000000X

    늘어지,100000000X

    늘어져,100000000X


  복합명사)

    어두워서:어두워서,어두워:0000

    어두워져:어두워져,어두워:0000

    어두워져서:어두워져서,어두워:0000

    늘어져서:늘어져서,늘어져:0000



- 복합용언 + '~요' 로 끝나는 용언 처리

  크고낮아요

  말려들어요


  복합명사)

    크고낮아:크고,낮아:0000

    말려들어:말려,들어:0000



- '~다', '~데' 로 끝나는 용언 처리

  크다

  작다

  큰데

  작은데

  '~다' 끝나는 용언이 형태소분리가 되기 위해서는 확장사전에 등록이 되어야 합니다.


  확장사전)

    크다,100000000X

    작다,100000000X

    큰데,100000000X

    작은데,100000000X

  


- '~ㄴ', '~은', '~는' 으로 끝나는 용언 처리

  짧은

  넒은

  튀어나온

  어울리는

    어울리,010000000X 용언 처리가 되어 있기 때문에 체언으로 fully 등록 합니다.

  잃어가는


  확장사전)

    짧은,100000000X

    넓은,100000000X

    튀어나온,100000000X

    잃어가는,100000000X

    어울리는,100000000X



- 'ㅎ' 불규칙 용언 처리

  노랗고

  동그랗고


  확장사전)

    노랗,100000000X


  복합명사)

    노랗고:노랗고,노랗:0000


- '~하', '~한' 으로 끝나는 용언 처리

  확장사전에 용언 처리가 되어 있는지 확인 합니다.

  용언 처리가 되어 있다면 체언으로 변경해 줍니다.

  확장사전에 ~하, ~한 을 제외 및 하다 동사 표기를 포함한 체언으로 등록 합니다.


  확장사전 1)

    넓적하,010000000X -> 100000000X

    넓적,100100000X

저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

[Arirang Analyzer - lucene 6.5.0] Term startOffset 정렬 오류

ITWeb/검색일반 2017.06.09 10:23

[arirang-analyzer-6.5.0]

  term analyzed 시 startOffset 정보에 대한 정렬이 역전 되는 오류

  개별 term 에서의 startOffset 이 역전 되기 때문에 아래 class 의 method 에서 정렬을 다시 맞춰줍니다.

  (정상적인 방법 이라기 보다는 일단 문제를 회피하기 위한 방법 입니다.)


  Class : KoreanFilter

  Method 1 :

    private void analysisKorean(String input) throws MorphException {


  //  input = trimHangul(input);

      List<AnalysisOutput> outputs = morph.analyze(input);

      if (outputs.size() == 0) {

        return;

      }


      Map<String, KoreanToken> map = new LinkedHashMap<String, KoreanToken>();

      if (hasOrigin) {

        map.put("0:" + input, new KoreanToken(input, offsetAtt.startOffset()));

      }


      extractKeyword(outputs, offsetAtt.startOffset(), map, 0);


      Collection<KoreanToken> values = map.values();

      for (KoreanToken kt : values) {

        kt.setOutputs(outputs);

      }


      // 이 부분에서 map 에 등록된 정보를 정렬 합니다.


      morphQueue.addAll(map.values());

    }


  Method 2 :

    private void analysisKorean(String input) throws MorphException {


  //  input = trimHangul(input);

      List<AnalysisOutput> outputs = morph.analyze(input);

      if (outputs.size() == 0) {

        return;

      }


      Map<String, KoreanToken> map = new LinkedHashMap<String, KoreanToken>();

      if (hasOrigin) {

        map.put("0:" + input, new KoreanToken(input, offsetAtt.startOffset()));

      }


      extractKeyword(outputs, offsetAtt.startOffset(), map, 0);


      Collection<KoreanToken> values = map.values();

      for (KoreanToken kt : values) {

        kt.setOutputs(outputs);

      }


      morphQueue.addAll(map.values());

      // 이 부분에서 morphQueue 에 등록된 정보를 정렬 합니다.

      morphQueue.sort(Comparator.comparingInt(KoreanToken::getOffset));

    }


  Method 3 : 

    protected void extractKeyword(List<AnalysisOutput> outputs, int startoffset,

      final Map<String, KoreanToken> map, int position) {

      ... 원본 코드 생략


      // 이 부분에서 map 에 대한 등록된 정보를 정렬 합니다.

    }


  정렬 방법 :

    참고) https://stackoverflow.com/questions/109383/sort-a-mapkey-value-by-values-java


    final List<Map.Entry<String, KoreanToken>> offsetSorts = map.entrySet().stream()

        .sorted(Map.Entry.comparingByValue(Comparator.comparingInt(KoreanToken::getOffset)))

        .collect(Collectors.toList());


    map.clear();


    offsetSorts.stream().forEachOrdered(e -> map.put(e.getKey(), e.getValue()));


  Method 4 :

    KoreanFilter 를 상속받아 CustomKoreanFilter 를 만들어 사용 하면 됩니다.


저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

[Arirang] first position increment must be > 0 오류

ITWeb/검색일반 2017.06.09 10:22

아직 확인 및 테스트 하지 않았습니다. ^^;

그냥 코드만 보고 이렇게 하면 되겠다 정도만 입니다.


- DefaultIndexingChain.java

first position increment must be > 0


관련 에러 수정을 위해서는 KoreanFilter.java 내 posIncrAtt.setPositionIncrement(iw.getPosInc()); 영역에서 

iw.getPosInc() 가 -1 인지 검사해서 1로 변경을 해줍니다.

변경에 따른 오류에 대해서 검토가 필요 합니다.


  private void setAttributesFromQueue(boolean isFirst) {

    final KoreanToken iw = morphQueue.removeFirst();

    if (isFirst && !morphQueue.isEmpty()) {

      // our queue has more elements remaining (e.g. we decompounded)

      // capture state for those. We set the term attribute to be empty

      // so we save lots of array copying later.

      termAtt.setEmpty();

      currentState = captureState();

    }

 

    termAtt.setEmpty().append(iw.getTerm());

    offsetAtt.setOffset(iw.getOffset(), iw.getOffset() + iw.getLength());

    morphAtt.setToken(iw);


    // on the first Token we preserve incoming increment:

    if (!isFirst) {

      posIncrAtt.setPositionIncrement(iw.getPosInc());

    }

    

    String type = TokenUtilities.getType(iw.getTerm().toCharArray(), iw.getTerm().length());

    typeAtt.setType(type);

    

    // TODO: How to handle PositionLengthAttribute correctly?

  }



저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

[검색] SEO 태그 가이드

ITWeb/검색일반 2017.05.31 16:52

- 네이버 검색 관련 가이드 : http://webmastertool.naver.com/guide/basic_optimize.naver

- 구글 검색 관련 가이드 : https://developers.google.com/search/docs/guides/search-gallery 

- 페이스북 오픈 그래프 태그 가이드 : https://developers.facebook.com/docs/sharing/webmasters#markup

- 페이스북 앱 링크 태그 가이드 : https://developers.facebook.com/docs/applinks/metadata-reference


저작자 표시 비영리 변경 금지
신고
tags : search, SEO, tag, 검색
Trackback 0 : Comment 0

[Lucene] Multi-value fields and the inverted index

ITWeb/검색일반 2017.01.19 18:41
아주 기초적인 것도 잊어버리는 것 같아 기록해 봅니다.

Multi-value fields and the inverted index

The fact that all field types support multi-value fields out of the box is a consequence of the origins of Lucene. Lucene was designed to be a full text search engine. In order to be able to search for individual words within a big block of text, Lucene tokenizes the text into individual terms, and adds each term to the inverted index separately.

This means that even a simple text field must be able to support multiple values by default. When other datatypes were added, such as numbers and dates, they used the same data structure as strings, and so got multi-values for free.


이 글은 아래 elasticsearch 에서 퍼왔습니다.


[문서]

https://www.elastic.co/guide/en/elasticsearch/reference/2.4/array.html

저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0