jjeong

원문 : http://lucene.apache.org/core/4_3_0/core/org/apache/lucene/codecs/lucene42/package-summary.html#Overview

--> Upgrade : lucene.apache.org/core/8_8_2/core/org/apache/lucene/codecs/lucene87/package-summary.html#package.description

Definitions

루씬의 기본 개념은 인덱스, 문서, 필드, 용어(색인어)라고 볼수 있습니다.

인덱스는 문서들의 순서를 포함합니다..

 

문서는 필드들의 집합.

 

필드는 용어들의 집합

 

용어(색인어)는 바이트의 집합.

 

두개의 다른 필드에 동일한 바이트의 순서는 다른 용어(색인어)로 간주됩니다. 

 

용어(색인어)는 문자이름을 가진 필드와 바이트를 포함한 필드의 쌍으로 구성됩니다.

Inverted Indexing

인덱스는 좀 더 효율적인 색인어 기반의 검색을 생성하기 위하여 색인어에 대한 통계를 저장 합니다.

 

루씬의 인덱스는 역 인덱스로 알려진 인덱스류로 구분되며, 색인어를 포함하는 문서를 나열 할 수 있기 때문 입니다.

 

친자연적 관계의 역 이라는 것은 문서 목록 색인어를 의미 합니다.

Types of Fields

루씬에서 필드들은 (필드 텍스트가 그대로 인덱스에 저장되어질 경우)비반전 방식으로 저장 될 수 있습니다.

 

반전된 필드들을 인덱스라고 부릅니다.

 

필드는 저장과 색인 둘 다 할 수 있습니다.

 

필드의 텍스트들은 색인되기 위해 색인어로 토큰화 될 수 있으며, 또는 색인되기 위해 그대로 사용 할 수도 있습니다.

 

대부분의 필드들은 토근화 됩니다. 그러나 때때로 어떤 식별자 필드들로 그대로 인덱스화하는 것이 유용하기도 하다.

Segments

루씬 인덱스들은 여러 하위 인덱스와 세그멘트들로 구성될 수 있으며, 각 세그멘트들은 완전 독립된 인덱스로 따로 따로 검색 될 수 있습니다.

 

인덱스에 의한 진화:

 

새로운 문서가 추가 되는 동안 신규 세그멘트가 생성하고.

 

기존 세그멘트들을 머지 합니다.

 

검색은 여러 세그멘트들과 인덱스들을 포함할 수 있습니다. 개별 인덱스 들은 잠재적으로 세그멘트의 집합으로 구성 되어 집니다.

Document Numbers

내부적으로 루씬은 정수형 문서번호에 의한 문서와 관련이 있습니다. 첫번째 문서는 0번을 가지고 인덱스에 추가 됩니다. 이후 각 문서들은 이전 보다 숫자 1이 더 큰 값을 가지고 추가 됩니다.

 

 

문서의 번호는 루씬 외부에서 저장할때 변경 될 수 있으니 주의 해야 합니다.

 

특히 문서번호는 다음과 같은 상황에서 변경 할 수 있습니다.

 

각 세그먼트에 저장된 번호들은 세그먼트 내에서 고유합니다. 그리고 큰 맥락에서 사용되기 전에 변환해야 합니다.

 

표준 기술은 세그먼트에서 사용된 번호들의 범위를 기반으로 값의 범위를 각 세그먼트에 할당 하게 됩니다.

 

세그먼트에서 외부 값으로 문서 번호를 변환 하기 위해서는 세그먼트의 기본 문서번호가 추가 됩니다.

 

세그먼트의 특정 값으로 다시 외부값을 변환 하려면, 세그먼트는 외부값의 범위에 의해서 식별 되어지고, 세그먼트의 기본 값은 빠집니다.

 

 

 

문서가 삭제 될때 문서번호 간격은 번호로 만들어집니다. 인덱스 병합을 통합으로서 결국 삭제 됩니다. 삭제 된 문서들은 세그먼트가 병합될때 삭제 됩니다. 새로 병합된 세그먼트들은 번호의 차이가 없습니다.

Index Structure Overview

각 세그먼트 인덱스 유지보수는 다음과 같습니다.

 

- 세그먼트 정보. 문서의 번호나 어떤 파일을 사용지와 같은 세그먼트의 메타정보를 포함 합니다.

 

- 인덱스에서 사용하는 필드 이름의 집합을 포함합니다.

 

- 저장된 필드 값. 문서에 대한 속성들은 필드 이름이고 속성-값 쌍 목록을 포함 합니다. 이것들은 문서에 대한 보조정보를 저장하기 위한 타이틀이나 URL 또는 데이터베이스에 접근하기 위한 식별자로 사용됩니다. 저장된 필드의 집합들은 검색 시 매칭된 개별로 반환 되어집니다. 반환된 값은 문서 번호에 의한 키입니다.

 

- 용어 사전. 색인된 모든 필드 와 문서에 들어 있는 색인어(용어)를 포함 하고 있습니다.

 

- 또한 사전은 색인어의 빈도와 근접 데이터의 포인터 그리고 용어를 포함하는 문서들의 번호를 포함 합니다.

 

- 색인어(용어) 빈도 데이터. 사전에서 각 용어를 위해, 문서 빈도 설정을 생략 하지 않는 다면 모든 문서와 문서 번호에서 용어를 포함 합니다.

 

- 용어 근접데이터. 사전에서 각 용어를 위해, 각 문서에서 발생한 용어의 위치, 생략 시 근접데이터 정보는 존재 하지 않습니다.

 

- 정규화 요소. 각 문서의 개별 필드를 위한 값이 히트 필드에 점수로 곱해져서 저장 됩니다.

 

- 용어 벡터. 각 문서의 개별 필드에 대해, 용어벡터(문서벡터) 가 저장 됩니다. 용어벡터는 용어 텍스트와 용어 빈도로 구성됩니다.

 

- 문서 별 값. 저장된 값과 같이 또한 문서 번호에 의해 구분 되어지며, 일반적으로 빠른 액세스를위한 메인 메모리에로드 될 것입니다. 저장된 값은 일반적으로 검색의 요약 결과를 구성하는 반면, 문서 별 값은 점수 요소 같은 것들에 유용합니다.

 

- 삭제된 문서. 문서 삭제 시 삭제 표시 옵션 입니다.

File Naming

모든 파일은 세그먼트에 속하며 다양한 확장자에  같은 이름을 갖습니다.

 

비록 이것이 필수 사항은 아니지만 전형적으로 인덱스의 모든 세그멘트는 단일 디렉토리에 저장됩니다.

 

버전 2.1 부터 파일 이름은 절대 재사용하지 않습니다. (segments.gen)

 

순차적인 long integer 로 생성 합니다.

Summary of File Extensions

TD, IDF 를 이용해서 Weight 를 줄 수 있으며, 아래와 같은 수식을 사용한다.

여기서 log 밑수는 10 입니다.

혹시라도 수학한지 너무 오래 되서 잊으셨을까봐.. ^^

참고 URL : http://kaistwebst.blog.me/130166255835

위 문서에 쉽게 설명이 나와 있습니다.

정리 하면, 하나의 문서 묶음(|S|)에서 어떤 단어(Wj) 가 한번 이라도 발생한 문서 수(Å)의 역수를 구하는 것입니다.

Term Wj 에 대한 idf 는 위와 같습니다.

그래서 TF-IDF 공식은 아래와 같습니다.

즉, idf 값이 작게 되면 문서의 중요도가 낮다고 볼 수 있습니다.

TF-IDF 값이 클 수록 검색어에 대한 찾는 문서에 가깝다고 이해 하면 되겠습니다.

참고 URL : http://kaistwebst.blog.me/130165776517

위 문서에 있는 것 처럼 하나의 문서에서 출현한 하나의 단어 출현 빈도수 입니다.

수식으로 표현 하면

예) 

DF 설명 : 색인어당 문서의 빈도 수 (색인어 A 가 들어 있는 문서 들 이라고 보면 됨)

얼마전에 릴리즈 되고 0.90.0 에 대한 미디오 컨퍼런스(?)도 했었죠.

관련 영상과 발표 문서 공유 합니다.

[영상]

[발표문서]

[요약]

날로 좋아 지고 있내요.. ^^

elasticsearch head plugin 사용하시 외부로 ES 서버가 노출되어 있는 경우 인증 부분을 고민 해야 합니다.

보통은 중간에 proxy 서버를 두어서 gateway 역할을 수행하게 하고 외부로 노출 안시키고 서비스를 할 수 있는데요.

혹시라도 proxy 구조를 두기 어렵다면 기본 인증이라도 적용하는게 좋지 않을까 합니다.

이미 ES 플러그인으로 제공되는 것이 있어서 링크 공유 합니다.

[head plugin]

https://github.com/mobz/elasticsearch-head

[http basic auth plugin]

https://github.com/karussell/elasticsearch-http-basic

[elasticsearch API 리뷰]

원문 링크 : http://www.elasticsearch.org/guide/reference/modules/cluster/

cluster 세팅 중 위 문서에 아래와 같은 설정이 있습니다.

Shard Allocation Awareness

sharding 과 replica 설정에 따라 clustering 환경에서 어떻게 배치 시킬것인지 관리 할 수 있도록 해주는 추가 설정 입니다.

즉, 특정 노드로 shard 를 배치 시키거나 replica 가 되도록 합니다.

아래는 이해를 돕기 위한 설정 예제 입니다.

[Rack 설정 예제]

[Zone 설정 예제]

※ Rack 의 경우 서로 다른 Rack 위치한 node 들에 대한 분산설정으로 같은 IDC 내 서로 다른 rack 이나 IDC 간 HA 구성이 가능 합니다.

※ Zone 의 경우 특정 zone 으로 동일 데이터가 몰려 SPOF 를 예방하기 위한 구성으로 사용이 가능 합니다.

직접 해보시면 쉽게 이해가 됩니다. :)

쉽게 개념을 잡기 위해 Document 색인 요청 시 어떤 flow 로 색인 및 복제를 하는지 간단하게 표현해 봤습니다.

                                    ↓

                                    ↓

[elasticsearch API 리뷰]

원문 링크 : http://www.elasticsearch.org/guide/reference/modules/plugins/

elasticsearch를 사용하면서 가장 많이 사용하는 것이 head 와 kr lucene 형태소 분석기가 아닌가 싶습니다.

그럼 이런 것들은 어떻게 제작을 해야 하는지 궁금 할텐데요.

위 원문 아래쪽에 제공되는 모든 plugin 목록을 보여 주고 있습니다.

또는 아래 링크에서도 확인이 가능 합니다.

[git]

- https://github.com/elasticsearch

- https://github.com/search?q=elasticsearch&type=&ref=simplesearch

우선 head와 같은 site plugin 구성 부터 살펴 보겠습니다.

이건 사실 설명이 필요 없습니다. ^^;;

[_site plugin]

[kr lucene analyzer plugin] 

- 이미 관련 plugin 은 제공 되고 있습니다.

- 아래 링크 참고

- 적용하는 방법은 두 가지 입니다.

    . First : elasticsearch-analysis-korean 을 설치 한다. (설치 시 es 버전을 맞춰 주기 위해서 별도 빌드가 필요 할 수도 있다.)

    . Second : lucene kr analyzer 라이브러리를 이용해서 plugin 형태로 제작해서 설치 한다.

- 아래는 plugin  형태로 제작해서 설치한 방법을 기술 한 것입니다.

- 만들어 봅시다.

- 이렇게 해서 빌드를 하시고 생성된 jar 파일을 위에서 언급한 경로에 위치 시키고 ES 재시작 후 아래와 같이 테스트 해보시면 됩니다.

[테스트]

{
  "tokens" : [ {
    "token" : "이것은",
    "start_offset" : 0,
    "end_offset" : 3,
    "type" : "word",
    "position" : 1
  }, {
    "token" : "이것",
    "start_offset" : 0,
    "end_offset" : 2,
    "type" : "word",
    "position" : 2
  }, {
    "token" : "루씬한국어",
    "start_offset" : 4,
    "end_offset" : 9,
    "type" : "word",
    "position" : 3
  }, {
    "token" : "루씬",
    "start_offset" : 4,
    "end_offset" : 6,
    "type" : "word",
    "position" : 4
  }, {
    "token" : "한국어",
    "start_offset" : 6,
    "end_offset" : 9,
    "type" : "word",
    "position" : 5
  }, {
    "token" : "형태소",
    "start_offset" : 10,
    "end_offset" : 13,
    "type" : "word",
    "position" : 6
  }, {
    "token" : "분석기",
    "start_offset" : 14,
    "end_offset" : 17,
    "type" : "word",
    "position" : 7
  }, {
    "token" : "분석",
    "start_offset" : 14,
    "end_offset" : 16,
    "type" : "word",
    "position" : 8
  }, {
    "token" : "플러그인",
    "start_offset" : 18,
    "end_offset" : 22,
    "type" : "word",
    "position" : 9
  }, {
    "token" : "플러그",
    "start_offset" : 18,
    "end_offset" : 21,
    "type" : "word",
    "position" : 10
  }, {
    "token" : "입니다",
    "start_offset" : 23,
    "end_offset" : 26,
    "type" : "word",
    "position" : 11
  }, {
    "token" : "입니",
    "start_offset" : 23,
    "end_offset" : 25,
    "type" : "word",
    "position" : 12
  } ] 

※ lucene 버전을 3.x 에서 4.x 로 올리고 싶으시다면 직접 코드 수정을 통해서 진행을 하시면 됩니다.

- elasticsearch-analysis-korean 의 경우는 고쳐야 할 부분이 좀 됩니다.

    . 우선 루씬 한국어 형태소 소스코드를 3.x 에서 4.x 로 올리셔야 합니다.

    . 관련 코드는 루씬 한국어 형태소 분석기 카페에 들어가 보시면 cvs 링크가 있습니다.

    . 추가로 es 버전도 올리고 싶으시다면 pom.xml 에서 코드를 수정해 주시기 바랍니다.

- 직접 플러그인을 생성해서 적용하는 방법은 위와 같이 플러그인을 만드시고 루씬한국어 형태소 분석기 라이브러리만 버전에 맞게 넣어서 사용하시면 됩니다.

    . 단, 플러그인의 pom.xml 에서 각 라이브러리의 version 은 맞춰 주셔야 겠죠.

[elasticsearch API 리뷰]

원문 링크 : http://www.elasticsearch.org/guide/reference/query-dsl/

- 많이 사용되는 것들로 진행 합니다.

[Filters]

기본적으로 filtered query 에서 동작 방식을 소개 했기 때문에 이 점을 이해하고 보셔야 합니다.

[and/or]

- 쿼리 결과에 대한 추가 쿼리의 and/or 연산을 수행 합니다.

- 쿼리 결과를 cache 하고 싶을 경우 _cache:true 설정을 하면 됩니다.

[bool]

- boolean 쿼리를 추가 수행 합니다.

[exists]

- 결과에 대해서 항상 cache 합니다.

[ids]

- ids 를 포함한 문서를 필터 합니다.

[limit]

- shard 당 문서 수를 제한 합니다.

[type]

- document/mapping type 에 대한 filter 합니다.

[missing]

- 문서의 특정 필드 값이 no value 인 것을 filter 합니다.

- 지정된 field 는 null_value 를 갖습니다.

- 예제가 직관적이기 떄문에 추가 합니다.

{
    "constant_score" : {
        "filter" : {
            "missing" : { 
                "field" : "user",
                "existence" : true,
                "null_value" : true
            }
        }
    }
}

[not]

- 질의된 결과에 대해서 추가로 주어진 not filter 로 match 된 문서를 제외 합니다.

[numeric range]

- range filter와 유사하며, 어떤 수의 범위를 갖습니다.

- 주어진 parameters 는 아래와 같습니다.

[prefix]

- phrase query 와 유사하며,  prefix query 참고

[query]

- 추가 query 를 생성 할 수 있습니다.

[range]

- range query 참고

[script]

- script 를 이용한 filter 를 적용 할 수 있습니다.

[term]

- term query 참고

[terms]

- terms query 참고

- execution mode 를 지원 합니다.

- 기본 plain 그리고 bool, and, or 지원

[nested]

- nested query 참고

※ filter 의 경우 기본 query 에서 제공 하는 것과 거의 동일 하며,

이 API 의 목적은 한번 질의한 결과에 대해 별도의 filtering 을 하기 위함 입니다.