'Elastic'에 해당되는 글 498건

  1. 2013.07.12 [lucene score] 펌) score 계산식.
  2. 2013.07.12 [elasticsearch] get score about nested type document.
  3. 2013.07.01 [Elasticsearch] Request URI 사용 시 검색 성능 관령 옵션.
  4. 2013.06.28 [elasticsearch] query timeout 개념 설명
  5. 2013.06.20 [elasticsearch] path_hierachy 설정
  6. 2013.06.19 [lucene]phrase query
  7. 2013.05.27 [lucene] field options for indexing - StringField.java
  8. 2013.05.22 [elasticsearch] mapping 분석 및 이해. 5
  9. 2013.05.22 [검색일반] elasticsearch + logstash + kibana
  10. 2013.05.21 [한글형태소분석기] 카이스트 한나눔 분석기.

[lucene score] 펌) score 계산식.

Elastic/Elasticsearch 2013. 7. 12. 17:29

Original URL : http://www.lucenetutorial.com/advanced-topics/scoring.html


Lucene Scoring

The authoritative document for scoring is found on the Lucene site here. Read that first.

Lucene implements a variant of the TfIdf scoring model. That is documented here.

The factors involved in Lucene's scoring algorithm are as follows:

  1. tf = term frequency in document = measure of how often a term appears in the document
  2. idf = inverse document frequency = measure of how often the term appears across the index
  3. coord = number of terms in the query that were found in the document
  4. lengthNorm = measure of the importance of a term according to the total number of terms in the field
  5. queryNorm = normalization factor so that queries can be compared
  6. boost (index) = boost of the field at index-time
  7. boost (query) = boost of the field at query-time

The implementation, implication and rationales of factors 1,2, 3 and 4 in DefaultSimilarity.java, which is what you get if you don't explicitly specify a similarity, are: 

note: the implication of these factors should be read as, "Everything else being equal, ... [implication]"

1. tf 
Implementation: sqrt(freq) 
Implication: the more frequent a term occurs in a document, the greater its score
Rationale: documents which contains more of a term are generally more relevant

2. idf
Implementation: log(numDocs/(docFreq+1)) + 1
Implication: the greater the occurrence of a term in different documents, the lower its score 
Rationale: common terms are less important than uncommon ones

3. coord
Implementation: overlap / maxOverlap
Implication: of the terms in the query, a document that contains more terms will have a higher score
Rationale: self-explanatory

4. lengthNorm
Implementation: 1/sqrt(numTerms)
Implication: a term matched in fields with less terms have a higher score
Rationale: a term in a field with less terms is more important than one with more

queryNorm is not related to the relevance of the document, but rather tries to make scores between different queries comparable. It is implemented as1/sqrt(sumOfSquaredWeights)

So, in summary (quoting Mark Harwood from the mailing list),

* Documents containing *all* the search terms are good
* Matches on rare words are better than for common words
* Long documents are not as good as short ones
* Documents which mention the search terms many times are good

The mathematical definition of the scoring can be found athttp://lucene.apache.org/core/4_0_0/core/org/apache/lucene/search/similarities/Similarity.html

Hint: look at NutchSimilarity in Nutch to see an example of how web pages can be scored for relevance

Customizing scoring

Its easy to customize the scoring algorithm. Subclass DefaultSimilarity and override the method you want to customize.

For example, if you want to ignore how common a term appears across the index,

Similarity sim = new DefaultSimilarity() {
  public float idf(int i, int i1) {
    return 1;
  }
}

and if you think for the title field, more terms is better

Similarity sim = new DefaultSimilarity() {
  public float lengthNorm(String field, int numTerms) {
    if(field.equals("title")) return (float) (0.1 *Math.log(numTerms));
    else return super.lengthNorm(field, numTerms);
  }
}


:

[elasticsearch] get score about nested type document.

Elastic/Elasticsearch 2013. 7. 12. 15:07

Nested type 의 Document Score 는 구할 수 없습니다.

ㅡ.ㅡ;;

그렇다고 이걸 해결 못하면 안되겠지요.

힌트, nested

:

[Elasticsearch] Request URI 사용 시 검색 성능 관령 옵션.

Elastic/Elasticsearch 2013. 7. 1. 20:23

elasticsearch Rest API 사용 시 검색 질의 성능 관련 파라미터 설명 입니다.

지난 번 보았던 timeout 은 collecting 실행 시간에 대한 제한 이였다면, 

이번에는 이런 문서를 질의 하고 수집 하는데 처리 하는 역할을 수행 하는 쓰레드 관련 설정 입니다.


/_search?operation_threading=threadPerShard


보시는 것 처럼 적용하기 쉽습니다.

이 옵션을 설정 하지 않을 경우 내부적으로 기본 single thread 로 동작 하게 됩니다.

이 경우 request 가 증가 하게 되면 당연히 성능이 떨어 질 수 밖에 없는 구조 입니다.

꼭 해당 옵션을 확인 해서 사용하시기 바랍니다.


아래는 Java API 에서 설정 하는 내용입니다.


.setOperationThreading(SearchOperationThreading.THREAD_PER_SHARD)


관련 소스파일 입니다.


RestSearchAction.java

SearchOperationThreading.java



이외 search_type도 있는데 이건 나중에 살펴 보죠.

:

[elasticsearch] query timeout 개념 설명

Elastic/Elasticsearch 2013. 6. 28. 21:46

elasticsearch 에서의 query timeout 에 대해 설명 합니다.


query timeout 은 두 가지 방법으로 설정이 가능 합니다.

1. Java API

setTimeout(millisecond)

2. Request URI (?timeout=10ms)

timeout=1S

S    : 1S = 1millisecond

ms : millisecond

s : second

m : minute

H : hour

d : day

w : week


기본 millisecond 입니다.


elasticsearch 에서는 query execution 후 중지 시킬 수 없습니다.

즉, timeout 을 지정 했다고 해서 실행 시간이 설정한 timeout 을 넘더라도 실행을 중지 하거나 connection 을 끊거나 하지 않습니다.


shard 들에 질의 후 문서를 collecting 하는데 실행 시간을 제한 하는 기능 입니다.

es 에서 구현된 기능이 아닌 lucene 에서 구현된 기능 입니다.


아래는 이해를 돕기 위한 관련 클래스 파일 입니다.

lucene

TimeLimitingCollector.java

elasticsearch

ContextIndexSearcher.java

TimeValue.java


:

[elasticsearch] path_hierachy 설정

Elastic/Elasticsearch 2013. 6. 20. 15:14

category 나 기타 tree 구조를 갖는 문서속성의 경우 path_hierachy 기능을 사용하면 유용한 부분이 있습니다.

단, 이 기능은 facet 사용은 못하니 참고 하시구요.


{

    "settings" : {

        "index" : {

            "analysis" : {

                "analyzer" : {

                    "path_analyzer" : {"tokenizer" : "path_hierarchy"}

                }

            }

        }

    },

    "mappings" : {

        "category" : {

            "properties" : {

                "category" : {

                    "type" : "multi_field",

                    "fields" : {

                        "name" : { "type" : "string", "index" : "not_analyzed" },

                        "path" : { "type" : "string", "analyzer" : "path_analyzer", "store" : true }

                    }

                }

            }

        }

    }

}



:

[lucene]phrase query

Elastic/Elasticsearch 2013. 6. 19. 14:22

http://www.avajava.com/tutorials/lessons/how-do-i-query-for-words-near-each-other-with-a-phrase-query.html


slop 관련 설명이 잘 되어 있어 공유 합니다.


Here are some foods that Deron likes:
hamburger
french fries
steak
mushrooms
artichokes
Query: contents:"french fries"
Number of hits: 1
Hit: C:\projects\workspace\demo\filesToIndex\deron-foods.txt

Query: contents:"hamburger steak"
Number of hits: 0

Query: contents:"hamburger steak"~1
Number of hits: 0

Query: contents:"hamburger steak"~2
Number of hits: 1
Hit: C:\projects\workspace\demo\filesToIndex\deron-foods.txt

Query: contents:"hamburger steak"~3
Number of hits: 1
Hit: C:\projects\workspace\demo\filesToIndex\deron-foods.txt

Searching for 'french fries' using QueryParser
Type of query: BooleanQuery
Query: contents:french contents:fries
Number of hits: 1
Hit: C:\projects\workspace\demo\filesToIndex\deron-foods.txt

Searching for '"french fries"' using QueryParser
Type of query: PhraseQuery
Query: contents:"french fries"
Number of hits: 1
Hit: C:\projects\workspace\demo\filesToIndex\deron-foods.txt

Searching for '"hamburger steak"~1' using QueryParser
Type of query: PhraseQuery
Query: contents:"hamburger steak"~1
Number of hits: 0

Searching for '"hamburger steak"~2' using QueryParser
Type of query: PhraseQuery
Query: contents:"hamburger steak"~2
Number of hits: 1
Hit: C:\projects\workspace\demo\filesToIndex\deron-foods.txt

Let's talk briefly about the console output. The first phrase query searches for "french" and "fries" with a slop of 0, meaning that the phrase search ends up being a search for "french fries", where "french" and "fries" are next to each other. Since this exists in deron-foods.txt, we get 1 hit.

In the second query, we search for "hamburger" and "steak" with a slop of 0. Since "hamburger" and "steak" don't exist next to each other in either document, we get 0 hits. The third query also involves a search for "hamburger" and "steak", but with a slop of 1. These words are not within 1 word of each other, so we get 0 hits.

The fourth query searches for "hamburger" and "steak" with a slop of 2. In the deron-foods.txt file, we have the words "... hamburger french fries steak ...". Since "hamburger" and "steak" are within two words of each other, we get 1 hit. The fifth phrase query is the same search but with a slop of 3. Since "hamburger" and "steak" are withing three words of each other (they are two words from each other), we get a hit of 1.

The next four queries utilize QueryParser. Notice that in the first of the QueryParser queries, we get a BooleanQuery rather than a PhraseQuery. This is because we passed QueryParser's parse() method "french fries" rather than "\"french fries\"". If we want QueryParser to generate a PhraseQuery, the search string needs to be surrounded by double quotes. The next query does search for "\"french fries\"" and we can see that it generates a PhraseQuery (with the default slop of 0) and gets 1 hit in response to the query.

The last two QueryParser queries demonstrate setting slop values. We can see that the slop values can be set the following the double quotes of the search string with a tilde (~) following by the slop number.

As we have seen, phrase queries are a great way to produce queries that have a degree of leeway to them in terms of the proximity and ordering of the words to be searched. The total allowed spacing between words can be controlled using the setSlop() method of PhaseQuery.


:

[lucene] field options for indexing - StringField.java

Elastic/Elasticsearch 2013. 5. 27. 10:52

lucene 3.6.X 에는 없는 클래스 입니다.

4.X 에서 처음 등장한 넘이구요.

코드를 조금 보면

public final class StringField extends Field {


  /** Indexed, not tokenized, omits norms, indexes

   *  DOCS_ONLY, not stored. */

  public static final FieldType TYPE_NOT_STORED = new FieldType();


  /** Indexed, not tokenized, omits norms, indexes

   *  DOCS_ONLY, stored */

  public static final FieldType TYPE_STORED = new FieldType();


  static {

    TYPE_NOT_STORED.setIndexed(true);

    TYPE_NOT_STORED.setOmitNorms(true);

    TYPE_NOT_STORED.setIndexOptions(IndexOptions.DOCS_ONLY);

    TYPE_NOT_STORED.setTokenized(false);

    TYPE_NOT_STORED.freeze();


    TYPE_STORED.setIndexed(true);

    TYPE_STORED.setOmitNorms(true);

    TYPE_STORED.setIndexOptions(IndexOptions.DOCS_ONLY);

    TYPE_STORED.setStored(true);

    TYPE_STORED.setTokenized(false);

    TYPE_STORED.freeze();

  }


  /** Creates a new StringField. 

   *  @param name field name

   *  @param value String value

   *  @param stored Store.YES if the content should also be stored

   *  @throws IllegalArgumentException if the field name or value is null.

   */

  public StringField(String name, String value, Store stored) {

    super(name, value, stored == Store.YES ? TYPE_STORED : TYPE_NOT_STORED);

  }

}


무조건 index true 입니다.

기존이랑은 좀 다르죠.

예전 옵션에 대한 정보만 가지고 있으면 실수 할 수도 있는 부분이라 살짝 올려봤습니다.

:

[elasticsearch] mapping 분석 및 이해.

Elastic/Elasticsearch 2013. 5. 22. 18:24

elasticsearch 에서 성능 및 운영에 있어서 기본이면서 핵심 내용이 될 수 있는 정보 입니다.

사실 이 내용만 잘 이해 하고 있으면 50% 이상 먹고 들어 갈 수 있습니다. ^^


mapping section

http://www.elasticsearch.org/guide/reference/mapping/


fields 와 types 를 확인해야 함.

fields

_id

document 의 unique id 는 _uid (_id + _type) 이며, _id 는 색인 ID 로 사용될 수 있다.

기본적으로 색인되지 않고 저장 하지 않습니다.

_type

기본적으로 색인은 하지만 저장은 하지 않습니다.

_source

자동으로 field 생성을 허용할지 결정 합니다.

_all

하나 또는 더 많은 field 를 색인시 저장 할 것인지 결정을 합니다.

"simple1" : {"type" : "long", "include_in_all" : true},

"simple2" : {"type" : "long", "include_in_all" : false}

_analyzer (설정 하지 않아도 되는 field)

색인 시 등록된 analyzer 또는 index_analyzer 를 사용 합니다.

또한, 특정 field 를 지정 할 경우 해당 field 에 정의된 analyzer 를 사용하게 됩니다.

_boost

문서나 field 의 연관성을 향상시키기 위해 사용한다.

_parent

parent type 을 지시하는 child mapping 정의 입니다.

blog type 과 blog_tag type 이 있을 경우 blog_tag 의 parent type 은 blog 가 됩니다.

_routing

색인 데이터에 대한 routing 관리를 위해서 사용 합니다.

routing field 는 store : yes, index : not_analyzed 로 설정이 되어야 합니다.

_index (설정 하지 않아도 되는 field)

index 가 소유한 문서를 store 합니다.

default false 로 저장 하지 않음.

_size (설정 하지 않아도 되는 field)

_source 에 의해서 자동으로 생성된 색인 field 의 수.

default disabled 입니다.

_timestamp

색인 시 문서의 timestamp 입니다.

기본 store : no, index : not_analyzed 이며,

설정 시 field 지정이 가능 합니다.

format 은 기본 dateOptionalTime. (http://www.elasticsearch.org/guide/reference/mapping/date-format/)

_ttl

색인 시 문서의 expiration date를 설정 합니다.

기본 disabled 입니다.

설정 시 ttl 이후 문서는 자동 삭제 됩니다.

core types

string type

index_name

array type 선언 시 사용되는 항목으로 array list 항목에 대한 개별 field 명으로 사용된다.

store

default no 이며, 저장에 대한 설정을 위해서 사용 된다.

yes 시 저장

index

검색 또는 색인 시 분석관련 설정을 위해서 사용 된다.

analyzed

검색과 색인 시 analyzer 를 이용해서 분석

not_analyzed

검색가능 하다는 의미

no

검색 불가능 하다는 의미

term_vector

기본 no 설정

no

yes

with_offsets

with_positions

with_positions_offsets

boost

기본 1.0

null_value

null value 시 기본 값은 아무것도 넣지 않으나 설정한 값이 있을 경우 등록 함.

omit_norms

기본 false 로 analyzed field 설정, true 일 경우 not_analyzed field 에서 설정

index_options

색인 옵션

docs

not_analyzed field

freqs

analyzed field

positions

analyzed field

analyzer

global 설정으로 검색과 색인 시 사용된다.

index_analyzer

색인 시에 사용된다.

search_analyzer

검색 시에 사용된다.

include_in_all

기본 true 로 설정 됨.

_all field 에 저장할 것인지 지정함.

ignore_above

지정한 크기 이상의 문자열을 무시 합니다.

position_offset_gap

number type

type : "float, double, byte, short, integer, and long",

index_name

store

index

precision_step

number 의 term value 를 만들어 냅니다.

설정 값이 작을 수록 검색은 빠르게 이루어 집니다.

기본 값은 4이며, 32bits 는 4 정도, 64bits 는 6~8정도를 사용합니다.

0 은 disable 입니다.

null_value

boost

include_in_all

ignore_malformed

비정상적인 숫자를 무시 한다.

기본 false로 설정 되어 있기 때문에 true 설정 하는 것이 좋다.

date type

index_name

format

http://www.elasticsearch.org/guide/reference/mapping/date-format.html

store

index

precision_step

number 의 term value 를 만들어 냅니다.

설정 값이 작을 수록 검색은 빠르게 이루어 집니다.

기본 값은 4이며, 32bits 는 4 정도, 64bits 는 6~8정도를 사용합니다.

0 은 disable 입니다.

null_value

boost

include_in_all

ignore_malformed

비정상적인 숫자를 무시 한다.

기본 false로 설정 되어 있기 때문에 true 설정 하는 것이 좋다.

boolean type

index_name

store

index

null_value

boost

include_in_all

binary type

index_name



default mapping template

"mapping" : {

"TYPE_NAME" : {

"analyzer" : "standard",

"index_analyzer" : "stadnard",

"search_analyzer" : "standard",

"_id" : {

"index" : "not_analyzed",

"store" : "yes",

"path" : "FIELD_NAME"

},

"_type" : {

"index" : "not_analyzed",

"store" : "yes"

},

"_source" : {

"enabled" : "false"

},

"_all" : {

"enabled" : "false"

},

"_boost" : {

"name" : "_boost",

"null_value" : 1.0

},

"_parent" : {

"type" : "PARENT_TYPE_NAME"

},

"_routing" : {

"required" : true,

"path" : "TYPE_NAME.FIELD_NAME"

},

"_timestamp" : {

"enabled" : true,

"path" : "DATE_FIELD_NAME",

"format" : "dateOptionalTime"

},

"properties" : {

"FIELD_NAME" : {

"type" : "string",

"index_name" : ,

"store" : ,

"index" : ,

"term_vector" : ,

"boost" : ,

"null_value" : ,

"omit_norms" : ,

"omit_term_freq_and_positions" : ,

"index_options" : ,

"analyzer" : ,

"index_analyzer" : ,

"search_analyzer" : ,

"include_in_all" : ,

"ignore_above" : ,

"position_offset_gap" : 

},

"FIELD_NAME" : {

"type" : "float, double, byte, short, integer, and long",

"index_name" : ,

"store" : ,

"index" : ,

"precision_step" : ,

"null_value" : ,

"boost" : ,

"include_in_all" : ,

"ignore_malformed" :

},

"FIELD_NAME" : {

"type" : "date",

"index_name" : ,

"format" : ,

"store" : ,

"index" : ,

"precision_step" : ,

"null_value" : ,

"boost" : ,

"include_in_all" : ,

"ignore_malformed" :

},

"FIELD_NAME" : {

"type" : "boolean",

"index_name" : ,

"store" : ,

"index" : ,

"null_value" : ,

"boost" : ,

"include_in_all" : ,

},

"FIELD_NAME" : {

"type" : "binary",

"index_name" : ,

}

}

}

}


:

[검색일반] elasticsearch + logstash + kibana

Elastic/Elasticsearch 2013. 5. 22. 17:47

로그를 수집해서 색인을 하고 검색 결과에 대한 분석 서비스가 나왔내요.

splunk 랑 비슷한 역할을 하는 오픈 소스라 elasticsearch 와 잘 조합해서 사용을 하면 splunk 보다 더 좋은 오픈소스 플랫폼이 나오지 않을까 싶내요.


[오픈소스 링크]

https://github.com/elasticsearch/kibana

http://logstash.net/

https://github.com/elasticsearch/elasticsearch


[주의사항]

index name format : logstash-yyyy.mm.dd

@timestamp : es datetime format

:

[한글형태소분석기] 카이스트 한나눔 분석기.

Elastic/Elasticsearch 2013. 5. 21. 03:53

오픈소스 한글 형태소 분석기 중 루씬 기반으로만 사용하다 보니 이런게 있는지 이제야 알았내요.. ^^;


http://kldp.net/projects/hannanum/



[SVN Checkout]



익명 Subversion 권한

이 프로젝트의 SVN 저장소는 다음과 같은 방법을 통해 익명으로 체크아웃하실 수 있습니다.
  • svn checkout --username anonsvn http://kldp.net/svn/hannanum
  • The password is 'anonsvn'



[Demo Run]

- 실행 전 JDK compiler 를 1.6 으로 변경해 주시기 바랍니다.

package kr.ac.kaist.swrc.jhannanum.demo; 아래 클래스 하나 실행 하시면 됩니다.

- Run As -> Java Application

: