不爲也 比不能也

Imagine that we have a website that allows users to search blog posts, such as these two documents:사용자들이 블로그 포스트를 검색할 수 있는 website를 가지고 있다고 가정해 보자. 다음과 같이 2개의 document가 있다.PUT /my_index/my_type/1 { "title": "Quick brown rabbits", "body": "Brown rabbits are commonly seen." } PUT /my_index/my_type/2 { "title": "Keeping pets healthy", "body": "My quick brown fox eats rabbits on a regular basis." }C..

What would happen if the user had searched instead for "quick pets"? Both documents contain the word quick, but only document 2 contains the word pets. Neither document contains both wordsin the same field.만약 사용자가 "quick pets" 을 검색한다면 어떻게 될까? 두 document 모두 quick 이라는 단어를 포함하고 있고, document 2만 pets 를 포함하고 있다. 동일한 field 에 두 단어 모두 를 포함하고 있는 document는 없다.A simple dis_max query like the following would..

The multi_match query provides a convenient shorthand way of running the same query against multiple fields.multi_match query는, 여러 field에 동일한 query를 실행하는, 아주 편리한 query이다.There are several types of multi_match query, three of which just happen to coincide with the three scenarios that we listed in Know Your Data: best_fields, most_fields, and cross_fields.multi_match query는 여러 가지 형태가 있다. Know You..

Full-text search is a battle between recall—returning all the documents that are relevant—and precision—not returning irrelevant documents. The goal is to present the user with the most relevant documents on the first page of results.full-text 검색은 recall(적합한 document 모두를 반환하는)과 정확성(precision)(부적합한 document를 반환하지 않는)의 전쟁이다. 결과의 첫 번째 page에 가장 적합한 document를 사용자에게 제시하는 것이 목표이다.To improve recall, we ..

Now we come to a common pattern: cross-fields entity search. With entities like person, product, or address, the identifying information is spread across several fields. We may have a person indexed as follows:이제 일반적인 패턴(여러 field에 대한 항목 검색 - cross fields entity search)을 시작해 보자. 사람(person), 제품(product), 주소(address) 같은 항목의 식별 정보는, 여러 field에 걸쳐 저장한다. 특정인의 정보는 아래처럼 색인될 것이다.{ "firstname": "Peter", "l..

All three of the preceding problems stem from most_fields being field-centric rather than term-centric: it looks for the most matching fields, when really what we’re interested in is the most matching terms.위의 세 가지 문제점 모두는, most_fields 가 단어 중심(term-centric) 이라기 보다는, field 중심(field-centric) 이라는 사실에서 기인한다. 실제로 관심을 가지는 것은 대부분이 일치하는 단어(terms) 인데, 대부분이 일치하는 fields 를 검색한다.The best_fields type is also ..

In Metadata: _all Field, we explained that the special _all field indexes the values from all other fields as one big string. Having all fields indexed into one field is not terribly flexible, though. It would be nice to have one custom _all field for the person’s name, and another custom _all field for the address.Metadata: _all Field에서, 하나의 큰 string으로 다른 모든 field의 값을 색인한 특별한 _all field를 설명한 바 ..

The custom _all approach is a good solution, as long as you thought about setting it up before you indexed your documents. However, Elasticsearch also provides a search-time solution to the problem: the multi_match query with type cross_fields. The cross_fields type takes a term-centric approach, quite different from the field-centric approach taken by best_fields and most_fields. It treats all ..

The final topic that we should touch on before leaving multifield queries is that of exact-value not_analyzed fields. It is not useful to mix not_analyzed fields with analyzed fields in multi_matchqueries.다중 field 검색을 마치기 전에, 다뤄야 할 마지막 주제는, exact-value not_analyzed field이다. multi_match query에서, not_analyzed field와 analyzed field를 섞는 것은 유용하지 않다.The reason for this can be demonstrated easily by lo..

Standard full-text search with TF/IDF treats documents, or at least each field within a document, as a big bag of words. The match query can tell us whether that bag contains our search terms, but that is only part of the story. It can’t tell us anything about the relationship between words.TF/IDF를 가진 표준 full-text 검색은, document나, 최소한 document내의 각각의 filed를, 단어가 들어 있는 큰 가방(bag of words) 으로 생각한다. 그..