2.X/1. Getting Started

1-06-3. Analysis and Analyzers

drscg 2017. 9. 30. 20:39

Analysis is a process that consists of the following:

analysis 프로세스는 다음과 같이 구성된다.

  • First, tokenizing a block of text into individual terms suitable for use in an inverted index,

    먼저, 문장(text)을, inverted index에서 사용하기에 적합한, 개별 단어(term) 로 분리한다.

  • Then normalizing these terms into a standard form to improve their "searchability" or recall

    그리고, "검색 능력", recall 을 개선하기 위해, 표준 형태로 이들 단어를 정규화한다.

This job is performed by analyzers. An analyzer is really just a wrapper that combines three functions into a single package:

이런 작업은 analyzer에 의해 수행된다. analyzer 는 실제로 하나의 package에 세가지 기능을 조합한 wrapper이다.

Character filters

First, the string is passed through any character filters in turn. Their job is to tidy up the string before tokenization. A character filter could be used to strip out HTML, or to convert &characters to the word and.

먼저, 문자열은 차례로 특정 character filter 에 전달된다. 그들의 기능은 분리(tokenization)하기 전에, 문자열을 정리하는 것이다. character filter는 HTML을 없애거나, & 문자를 단어 and 로 바꾸는 데 사용된다.

Tokenizer

Next, the string is tokenized into individual terms by a tokenizer. A simple tokenizer might split the text into terms whenever it encounters whitespace or punctuation.

다음은, tokenizer 로, 문장(text)을 개별 단어로 분리하는 것이다. 간단한 tokenizer는 공백이나 문장 부호를 만날 때마다, 텍스트를 분할하여 단어로 만든다.

Token filters

Last, each term is passed through any token filters in turn, which can change terms (for example, lowercasing Quick), remove terms (for example, stopwords such as aandthe) or add terms (for example, synonyms like jump and leap).

마지막으로, 각 단어는 차례로 특정 token filter 에 전달된다. 이것은 단어를 변경하거나(Quick 의 소문자화), 단어를 제거하거나(aandthe 같은 불용어), 단어를 추가한다(jump 와 leap 같은 동의어).

Elasticsearch provides many character filters, tokenizers, and token filters out of the box. These can be combined to create custom analyzers suitable for different purposes. We discuss these in detail in Custom Analyzers.

Elasticsearch는 많은 character filters, tokenizer, token filter를 기본으로 제공한다. 서로 다른 목적에 적합하도록, 사용자 정의 analyzer를 만들기 위해, 이들은 조합될 수 있다. Custom Analyzers에서 자세히 이야기 해 보자.

Built-in Analyzersedit

However, Elasticsearch also ships with prepackaged analyzers that you can use directly. We list the most important ones next and, to demonstrate the difference in behavior, we show what terms each would produce from this string:

그러나, Elasticsearch는 바로 사용할 수 있는, 미리 만들어진 많은 analyzer를 가지고 있다. 가장 중요한 몇 가지를 나열해 보았다. 동작 방식의 차이점을 보여주기 위해, 아래 문자열로 각각 어떤 단어를 만들어 내는지 알아보자.

"Set the shape to semi-transparent by calling set_trans(5)"
Standard analyzer

The standard analyzer is the default analyzer that Elasticsearch uses. It is the best general choice for analyzing text that may be in any language. It splits the text on word boundaries, as defined by the Unicode Consortium, and removes most punctuation. Finally, it lowercases all terms. It would produce

standard analyzer는 Elasticsearch가 사용하는 기본 analyzer이다. 어떤 언어이든, 문장(text)을 분석하는 가장 일반적인 선택이다. Unicode Consortium에 정의된 대로, 단어 경계(word boundary) 에서 문장(text)을 분할하고, 대부분의 문장 부호를 제거한다. 마지막으로, 모든 단어를 소문자로 만든다.

set, the, shape, to, semi, transparent, by, calling, set_trans, 5
Simple analyzer

The simple analyzer splits the text on anything that isn’t a letter, and lowercases the terms. It would produce

simple analyzer는 문자가 아닌 것을 기준으로, 문장(text)을 분할하고, 단어를 소문자로 만든다.

set, the, shape, to, semi, transparent, by, calling, set, trans
Whitespace analyzer

The whitespace analyzer splits the text on whitespace. It doesn’t lowercase. It would produce

whitespace analyzer는 공백을 기준으로, 문장(text)을 분할한다. 소문자로 만들지 않는다.

Set, the, shape, to, semi-transparent, by, calling, set_trans(5)
Language analyzers

Language-specific analyzers are available for many languages. They are able to take the peculiarities of the specified language into account. For instance, the english analyzer comes with a set of English stopwords (common words like and or the that don’t have much impact on relevance), which it removes. This analyzer also is able to stem English words because it understands the rules of English grammar.

language-specific analyzer는 많은 언어에 이용할 수 있다. 지정한 언어의 특징을 설명으로 제공한다. 예를 들면, english analyzer는 영어의 불용어(stopwords, relevance에 영향을 미치지 않는 andthe같은 일반적인 단어) 집합이 들어 있다. 이런 불용어는 제거된다. 영어 문법을 이해하기 때문에, 영어 단어를 형태소 분석(stem) 할 수 있다.

The english analyzer would produce the following:

english analyzer는 아래와 같은 단어를 만들어 낸다.

set, shape, semi, transpar, call, set_tran, 5

Note how transparentcalling, and set_trans have been stemmed to their root form.

transparentcallingset_trans 가 그들의 원형으로 형태소 분석되었다는 점을, 유심히 보자.

When Analyzers Are Usededit

When we index a document, its full-text fields are analyzed into terms that are used to create the inverted index. However, when we search on a full-text field, we need to pass the query string through the same analysis process, to ensure that we are searching for terms in the same form as those that exist in the index.

document를 색인 하는 경우, full-text field는, inverted index를 생성하기 위해 사용되는 단어로, 분석된다. 그러나 full-text field를 검색 하는 경우, index에 존재하는 단어와 동일한 형태의 단어를 검색한다는 것을 보장하기 위해, query string도 동일한 분석(analysis) 프로세스 를 거치도록 해야 한다.

Full-text queries, which we discuss later, understand how each field is defined, and so they can dothe right thing:

나중에 이야기 하겠지만, full-text query는, 각 field가 정의된 방법을 알고 있기 때문에, 올바른 검색을 할 수 있다.

  • When you query a full-text field, the query will apply the same analyzer to the query string to produce the correct list of terms to search for.

    full-text field를 query하는 경우, query는 검색 하려는 단어의 올바른 목록을 만들기 위해, query string에 동일한 analyzer를 적용한다.

  • When you query an exact-value field, the query will not analyze the query string, but instead search for the exact value that you have specified.

    exact-value field를 query하는 경우, query는 query string을 분석하지 않는다. 대신 지정한 exact value를 검색한다.

Now you can understand why the queries that we demonstrated at the start of this chapter return what they do:

이제 이 장의 초반에 보여주었던 query의 결과가 왜 그러한지, 이해할 수 있을 것이다.

  • The date field contains an exact value: the single term 2014-09-15.

    date field는 exact value를 포함한다. 단일 단어 2014-09-15

  • The _all field is a full-text field, so the analysis process has converted the date into the three terms: 201409, and 15.

    _all field는 full-text field이다. 따라서, 분석 프로세스는 date를 3개의 단어로 바꾼다. 20140915

When we query the _all field for 2014, it matches all 12 tweets, because all of them contain the term 2014:

_all field를 2014 로 query하면, tweet 모두가 2014 라는 단어를 포함하고 있기 때문에, 12개의 tweet 모두가 일치한다.

GET /_search?q=2014              # 12 results

When we query the _all field for 2014-09-15, it first analyzes the query string to produce a query that matches any of the terms 201409, or 15. This also matches all 12 tweets, because all of them contain the term 2014:

_all field를 2014-09-15 로 query하면, 먼저 20140915 중 어떤(any) 단어에 일치하는 query를 만들기 위해, query string을 분석한다. 이 또한, tweet 모두가 2014 라는 단어를 포함하고 있기 때문에, 12개의 tweet 모두가 일치한다.

GET /_search?q=2014-09-15        # 12 results !

When we query the date field for 2014-09-15, it looks for that exact date, and finds one tweet only:

date field를 2014-09-15 로 query하면, exact date를 검색하고, 하나의 tweet만 발견한다.

GET /_search?q=date:2014-09-15   # 1  result

When we query the date field for 2014, it finds no documents because none contain that exact date:

date field를 2014 로 query하면, 어떤 document도 exact date를 포함하고 있지 않기 때문에, 어떤 document도 발견하지 못한다.

GET /_search?q=date:2014         # 0  results !

Testing Analyzersedit

Especially when you are new to Elasticsearch, it is sometimes difficult to understand what is actually being tokenized and stored into your index. To better understand what is going on, you can use the analyze API to see how text is analyzed. Specify which analyzer to use in the query-string parameters, and the text to analyze in the body:

특히 Elasticsearch가 처음이면, 실제로 무엇이 token화 되고 index에 저장되는지를 이해하는 것이 어려울 것이다. 어떻게 되는지를 더 잘 이해하기 위해, 문장(text)이 분석되는 방법을 알기 위해, analyze API를 사용할 수 있다. query-string 매개변수에 사용할 analyzer를 지정하고, body에 분석할 문장(text)을 지정하자.

GET /_analyze
{
  "analyzer": "standard",
  "text": "Text to analyze"
}

Each element in the result represents a single term:

결과의 각 요소는 하나의 단어를 나타낸다.

{
   "tokens": [
      {
         "token":        "text",
         "start_offset": 0,
         "end_offset":   4,
         "type":         "<ALPHANUM>",
         "position":     1
      },
      {
         "token":        "to",
         "start_offset": 5,
         "end_offset":   7,
         "type":         "<ALPHANUM>",
         "position":     2
      },
      {
         "token":        "analyze",
         "start_offset": 8,
         "end_offset":   15,
         "type":         "<ALPHANUM>",
         "position":     3
      }
   ]
}

The token is the actual term that will be stored in the index. The position indicates the order in which the terms appeared in the original text. The start_offset and end_offset indicate the character positions that the original word occupied in the original string.

token 은 index에 저장될 실제 단어이다. position 은 원래 문장(text)에서, 단어가 나타나는 순서를 가리킨다. start_offset 과 end_offset 은 원래의 문자열에서 원래의 단어가 차지하는 문자의 위치를 가리킨다.

Tip

The type values like <ALPHANUM> vary per analyzer and can be ignored. The only place that they are used in Elasticsearch is in the keep_types token filter.

영숫자<ALPHANUM> 같은 type 의 값은 analyzer별로 다르고, 무시될 수 있다. Elasticsearch에서 그것들이 사용되는 유일한 곳은 keep_types token filter이다.

The analyze API is a useful tool for understanding what is happening inside Elasticsearch indices, and we will talk more about it as we progress.

analyze API는, Elasticsearch indices 내부에서 어떤 일이 일어나는지 이해하는데 있어, 유용한 도구이다. 앞으로 이에 대해 더 많이 이야기 할 것이다.

Specifying Analyzersedit

When Elasticsearch detects a new string field in your documents, it automatically configures it as a full-text string field and analyzes it with the standard analyzer.

Elasticsearch가 document에서 새로운 string field를 찾으면, 자동으로 full-text string field로 설정하고, standard analyzer로 분석한다.

You don’t always want this. Perhaps you want to apply a different analyzer that suits the language your data is in. And sometimes you want a string field to be just a string field—to index the exact value that you pass in, without any analysis, such as a string user ID or an internal status field or tag.

항상 이렇게 되는 것을 바라지는 않을 것이다. 데이터가 가지고 있는 언어에 적합한, 다른 analyzer를 적용하려 할 것이다. 그리고, 때로는 string field를 string field 자체로 원할 것이다. 문자열 사용자 ID나 내부 상태 field, tag 같은 것은, 분석 없이, 넘겨준 정확한 값 그대로 색인하기를 원할 것이다.

To achieve this, we have to configure these fields manually by specifying the mapping.

이렇게 하려면, mapping을 지정하여, 이 field를 수동으로 설정해야 한다.


'2.X > 1. Getting Started' 카테고리의 다른 글

1-06-1. Exact Values Versus Full Text  (0) 2017.09.30
1-06-2. Inverted Index  (0) 2017.09.30
1-06-4. Mapping  (0) 2017.09.30
1-06-5. Complex Core Field Types  (0) 2017.09.30
1-07. Full-Body Search  (0) 2017.09.30