4-06-3. Post Filter

So far, we have a way to filter both the search results and aggregations (a non-scoring filterquery), as well as filtering individual portions of the aggregation (filter bucket).

이제, 검색 결과와 aggregation 양쪽 모두를 filtering(non-scoring filter query)하고, aggregation의 개별 부분을 filtering(filter bucket)하는 방법을 알게 되었다.

You may be thinking to yourself, "hmm…is there a way to filter just the search results but not the aggregation?" The answer is to use a post_filter.

"그럼, aggregation이 아니라 단지 검색 결과만 filtering하는 방법이 있을까?" 라는 생각이 들것이다. 정답은 post_filter 를 사용하는 것이다.

This is a top-level search-request element that accepts a filter. The filter is applied after the query has executed (hence the post moniker: it runs post query execution). Because it operates after the query has executed, it does not affect the query scope—and thus does not affect the aggregations either.

이것은 filter를 가지는, 최고 수준(top-level)의 검색 request 요소이다. query가 실행된 후에, filter가 적용된다. (query가 실행된 다음(post)에 그것이 실행되기 때문에, post 라는 이름으로 불린다.) query가 실행된 후에 그것이 동작하기 때문에, query의 범위에 영향을 미치지 않는다. 따라서, aggregation에도 영향을 미치지 않는다.

We can use this behavior to apply additional filters to our search criteria that don’t affect things like categorical facets in your UI. Let’s design another search page for our car dealer. This page will allow the user to search for a car and filter by color. Color choices are populated via an aggregation:

UI의 카테고리 같은 것에 영향을 미치지 않고, 검색 기준에 추가 filter를 적용하기 위하여, 이 기능을 사용할 수 있다. 자동차 판매상을 위한 또 다른 검색 페이지를 계획해 보자. 이 페이지는 사용자가 자동차를 검색하고, 색상으로 filtering할 수 있다. 색상 선택은 aggregation으로 채워진다.

GET /cars/transactions/_search
{
    "size" : 0,
    "query": {
        "match": {
            "make": "ford"
        }
    },
    "post_filter": {    
        "term" : {
            "color" : "green"
        }
    },
    "aggs" : {
        "all_colors": {
            "terms" : { "field" : "color" }
        }
    }
}

COPY AS CURLVIEW IN SENSE 

post_filter 요소는 최고 수준(top-level) 의 요소이고, 검색 hit만을 filtering한다.

The query portion is finding all ford cars. We are then building a list of colors with a termsaggregation. Because aggregations operate in the query scope, the list of colors will correspond with the colors that Ford cars are painted.

query 부분은 ford 자동차를 검색한다. 그 다음에 terms aggregation으로, 색상 목록을 만든다. aggregation은 query 범위에서 동작하기 때문에, 색상 목록은 Ford 자동차에 칠해진 색상에 대응할 것이다.

Finally, the post_filter will filter the search results to show only green ford cars. This happens after the query is executed, so the aggregations are unaffected.

마지막으로, post_filter 는 녹색 ford 자동차만을 보여주기 위해, 검색 결과를 filtering한다. 이것은 query가 실행된 후에 발생한다. 따라서 aggregation에 영향을 미치지 않는다.

This is often important for coherent UIs. Imagine that a user clicks a category in your UI (for example, green). The expectation is that the search results are filtered, but not the UI options. If you applied a Boolean filter query, the UI would instantly transform to show only green as an option—not what the user wants!

이것은 일관성 있는 UI에 있어 중요하다. 사용자가 UI에서 특정 카테고리(예: green)를 클릭한다고 가정해 보자. 기대하는 것은 검색 결과가 filtering되는 것이지, UI의 옵션이 아니다. filtered query를 적용하면, UI는 옵션인 green 만 을 보여주기 위해, 즉시 바뀔 것이다. 사용자가 바라는 것이 아니다.

Performance consideration

Use a post_filter only if you need to differentially filter search results and aggregations. Sometimes people will use post_filter for regular searches.

검색 결과와 aggregation을 따로 filtering할 경우에만, post_filter 를 사용하자. 가끔 사람들은 일반 검색에 post_filter 를 사용한다.

Don’t do this! The nature of the post_filter means it runs after the query, so any performance benefit of filtering (such as caches) is lost completely.

이렇게 하지 말자. post_filter 의 본질은 query 후 에, 동작하는 것이다. 그렇게 하면, filtering의 성능상 이점(cache 등)을 완전히 잃어버린다.

The post_filter should be used only in combination with aggregations, and only when you need differential filtering.

post_filter 는 aggregation과 조합해서만, 그리고 차별적인 filtering이 필요할 경우에만, 사용되어야 한다.