'guide'에 해당되는 글 30건

  1. 2015.12.22 [Elasticsearch - The Definitive Guide] One Language per Document.
  2. 2015.12.22 [Elasticsearch - The Definitive Guide] Single Query String
  3. 2015.12.22 [Elasticsearch - The Definitive Guide] Pitfalls of Mixing Languages
  4. 2015.12.16 [Elasticsearch - The Definitive Guide] Dealing with Human Language
  5. 2015.12.16 [Elasticsearch - The Definitive Guide] Controlling Relevance
  6. 2015.12.15 [Elasticsearch - The Definitive Guide] Index Time Optimizations
  7. 2015.12.15 [Elasticsearch - The Definitive Guide] Finding Associated Words
  8. 2015.12.15 [Elasticsearch - The Definitive Guide] Improving Performance
  9. 2015.12.15 [Elasticsearch - The Definitive Guide] Phrase Matching
  10. 2015.12.15 [Elasticsearch - The Definitive Guide] Exact Value Fields

[Elasticsearch - The Definitive Guide] One Language per Document.

Elastic/TheDefinitiveGuide 2015.12.22 11:18

다국어 지원시 인덱스 모델링 시 type 을 사용하지 말라는 주의 문구가 있어서 기록 합니다.

혹시라도 type 을 통한 구성을 고민 하고 계셨다면 한번 읽어 보시면 좋을 것 같습니다.


원문링크)


원문 Snippet)

Don’t Use Types for Languages

You may be tempted to use a separate type for each language, instead of a separate index. For best results, you should avoid using types for this purpose. As explained in Types and Mappings, fields from different types but with the same field name are indexed into the same inverted index. This means that the term frequencies from each type (and thus each language) are mixed together.

To ensure that the term frequencies of one language don’t pollute those of another, either use a separate index for each language, or a separate field, as explained in the next section.


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

[Elasticsearch - The Definitive Guide] Single Query String

Elastic/TheDefinitiveGuide 2015.12.22 11:13

여러 필드에 질의 할 때 문서에 대한 score 계산시 가장 relevant 한 결과를 만들어 내기 위해 사용하는 기법이라고 보면 될 것 같습니다.

하지만 기능적으로 어떤의미를 갖는지를 알아야 응용이 가능 하겠습니다.


원문링크)


원문 Snippet)

Best fields
When searching for words that represent a concept, such as “brown fox,” the words mean more together than they do individually. Fields like the title and body, while related, can be considered to be in competition with each other. Documents should have as many words as possible in the same field, and the score should come from the best-matching field.
Most fields

A common technique for fine-tuning relevance is to index the same data into multiple fields, each with its own analysis chain.

The main field may contain words in their stemmed form, synonyms, and words stripped of theirdiacritics, or accents. It is used to match as many documents as possible.

The same text could then be indexed in other fields to provide more-precise matching. One field may contain the unstemmed version, another the original word with accents, and a third might use shinglesto provide information about word proximity.

These other fields act as signals to increase the relevance score of each matching document. The more fields that match, the better.

Cross fields

For some entities, the identifying information is spread across multiple fields, each of which contains just a part of the whole:

  • Person: first_name and last_name
  • Book: title, author, and description
  • Address: street, city, country, and postcode


가볍게 요약하면 이렇습니다.

- best fields 는 가장 적합한 field 의 score 를 리턴 합니다.

- most fields 는 field 들의 score 를 더한 값을 리턴 합니다.

- cross fields 는 field 들을 섞어서 score 를 계산 하여 리턴 합니다. (field 들 중 최소의 idf 값을 사용 합니다.)


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

[Elasticsearch - The Definitive Guide] Pitfalls of Mixing Languages

Elastic/TheDefinitiveGuide 2015.12.22 10:48

여러 종류의 언어가 섞여 있는 경우에 대한 이야기 입니다.

다국어 지원 자체는 기능적 요건에 따라 구현 방법이 달라 질 수 있기 때문에 고민을 많이 할 수 밖에 없는 것 같습니다.

Elasticsearch 에서는 쉬운 접근법으로 _all 과 custom all (copy_to, multi fields) 기능을 제시해 주고 있습니다.

이 글에서는 저 한테 필요한 내용인 language detection 관련 링크가 있어 기록해 봅니다.


원문링크)


Language Detection)


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

[Elasticsearch - The Definitive Guide] Dealing with Human Language

Elastic/TheDefinitiveGuide 2015.12.16 17:47

글 제목과 비슷할 수도 다를 수도 있습니다.

precision 과 recall 에 대한 설명이 짧게 잘 표현이 되어 있어서 기록해 봅니다.


원문링크)


원문 Snippet)

Full-text search is a battle between precision—returning as few irrelevant documents as possible—andrecall—returning as many relevant documents as possible.


원래 이 문서는 언어에 대한 처리 목적 이였습니다.

그래서 정의한 5가지 title 만 정리해 봤습니다.


- Normalizing Tokens

추출 된 token 에서 필요 없는 character를 제거 합니다.

- Reducing Words To Their Root Form

Word 에 붙은 불필요한 정보를 제거 합니다. (word의 origin을 만든다고 보시면 쉽습니다.)

- Stopwords

불용어 처리를 합니다. (즉, 색인 대상에서 제외 시킵니다.)

- Synonyms

동의어 또는 유의어 처리를 합니다.

- Typoes and Mispelings

오타 처리를 합니다.

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

[Elasticsearch - The Definitive Guide] Controlling Relevance

Elastic/TheDefinitiveGuide 2015.12.16 14:08

Relevance 관련 글이 많아서 일단 한번쯤은 꼭 읽어 봐야 하는 글만 모아 봤습니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/query-scoring.html

- 이 글에서는 bool query에 대한 query competition 에 대한 내용이 포함 되어 있습니다.


https://www.elastic.co/guide/en/elasticsearch/guide/current/not-quite-not.html

- 이 글에서는 boosting query에 대한 내용이 포함 되어 있습니다.


https://www.elastic.co/guide/en/elasticsearch/guide/current/ignoring-tfidf.html

- 이 글에서는 constant_score query에 대한 내용이 포함 되어 있습니다.

- 즉, 모든 점수가 1로 나오며, boosting 설정 값에 따라 score 를 부여하게 됩니다.


https://www.elastic.co/guide/en/elasticsearch/guide/current/boosting-by-popularity.html

- 이 글에서는 function_score query에 대한 내용이 포함 되어 있습니다.

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

[Elasticsearch - The Definitive Guide] Index Time Optimizations

Elastic/TheDefinitiveGuide 2015.12.15 13:51

그냥 좋은 내용이라 기록 합니다.


원문링크)


원문 Snippet)

The flexibility of query-time operations comes at a cost: search performance. Sometimes it may make sense to move the cost away from the query. In a real- time web application, an additional 100ms may be too much latency to tolerate.

By preparing your data at index time, you can make your searches more flexible and improve performance. You still pay a price: increased index size and slightly slower indexing throughput, but it is a price you pay once at index time, instead of paying it on every query.


짧게 정리 하면)

- query-time operation 은 비용이 들지만 flexible 하다.

- index-time operation 은 색인 성능이 떨어지고 저장공간이 늘어 날 수 있지만 질의 성능이 좋아지고 더욱 유연하게 사용할 수 있게 해준다.


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

[Elasticsearch - The Definitive Guide] Finding Associated Words

Elastic/TheDefinitiveGuide 2015.12.15 12:46

문서에 대한 relevance를 어떻게 구현해야 비용이 적게 들까? 고민 해보신 적이 있을 실겁니다.

꼭 이 글이 일치 하지는 않지만 match query 사용 시 비싼 비용을 지불하지 말고 indexing time 에 활용을 한번 해보면 어떨까 하는 아이디어에서 나온 글로 보시면 어떨까 합니다.

그런 의미에서 기록해 봤습니다.


원문링크)


원문 Snippet)

Performanceedit

Not only are shingles more flexible than phrase queries, but they perform better as well. Instead of paying the price of a phrase query every time you search, queries for shingles are just as efficient as a simplematch query. A small price is paid at index time, because more terms need to be indexed, which also means that fields with shingles use more disk space. However, most applications write once and read many times, so it makes sense to optimize for fast queries.

This is a theme that you will encounter frequently in Elasticsearch: enables you to achieve a lot at search time, without requiring any up-front setup. Once you understand your requirements more clearly, you can achieve better results with better performance by modeling your data correctly at index time.


shingles 란? 쉽게 token(term)들에 대한 ngram 이라고 이해 하시면 쉽습니다.


결국 검색 질의 시 slop 이나 position_offset_gap 기능을 이용하는 것 보다 색인 시 shigles analyzed 를 통해 질의 비용을 줄이는 것이라고 보시면 됩니다.

단, 문서에도 있지만 저장 공간이 늘어 나게 됩니다.

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

[Elasticsearch - The Definitive Guide] Improving Performance

Elastic/TheDefinitiveGuide 2015.12.15 12:24

검색 질의에 대한 성능 향상 관련 글 입니다.

한번 쯤 읽어 보시면 좋을 것 같아 기록 합니다.


원문링크)


요약)

- term query 가 match query 종류 보다 10배 에서 20배 빠릅니다.

- 그렇다고 해서 match query 종류가 느린것은 아닙니다. ( 수 밀리초 내 응답 합니다.)

- slop, position_offset_gap 과 같은 속성 사용에 대한 이해가 필요합니다.


Rescoring 이라는 것이 나오는데요.

이건 function_score 랑도 비슷합니다.

하지만 두 개의 목적은 비슷하지만 사용법은 다르죠.

결과적으로 두 API 다 개별 shard 에서의 top N 개의 문서를 가지고 다시 rescoring 하게 된다는 것입니다.

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

[Elasticsearch - The Definitive Guide] Phrase Matching

Elastic/TheDefinitiveGuide 2015.12.15 11:20

match query type 중 phrase 에 대한 이해를 돕기 위해 기록 합니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/phrase-matching.html


원문 Snippet)

What Is a Phraseedit

For a document to be considered a match for the phrase “quick brown fox,” the following must be true:

  • quick, brown, and fox must all appear in the field.
  • The position of brown must be 1 greater than the position of quick.
  • The position of fox must be 2 greater than the position of quick.

If any of these conditions is not met, the document is not considered a match.

Tip

Internally, the match_phrase query uses the low-level span query family to do position-aware matching. Span queries are term-level queries, so they have no analysis phase; they search for the exact term specified.

Thankfully, most people never need to use the span queries directly, as the match_phrasequery is usually good enough. However, certain specialized fields, like patent searches, use these low-level queries to perform very specific, carefully constructed positional searches.

다시 한번 정리 하면,

position-aware matching 을 이용하는 span query

- 첫번째 term 에 대한 position에 의해 나머지 term 들의 matching position 은 quick의 position 보다 커야 합니다.

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

[Elasticsearch - The Definitive Guide] Exact Value Fields

Elastic/TheDefinitiveGuide 2015.12.15 10:57

주의 사항이라 기록해 봅니다.


원문링크)


원문 Snippet)

Avoid using not_analyzed fields in multi_match queries.


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