jjeong

공식 문서)

Exists query | Elasticsearch Guide [7.16] | Elastic

exists query 는 field 자체가 아래 이유등으로 인해 생성 되자 않는 문서를 찾습니다.

즉, 

- null 또는 empty array (빈문자열 "" 은 해당 되지 않습니다.)

- index: false

- ignore_above 설정 값을 넘었을 때

- ignore_malformed 설정에 걸렸을 때

검색 엔진 특성상 null, empty string 에 대해서는 전처리를 통해서 명확히 제거 하거나 목적에 맞게 변형 하는 것이 좋습니다.

검색엔진을 이용해서 field:"" 또는 field: " " 과 같은 질의를 작성 하는 것은 좋지 않습니다.

보셔야 하는 클래스는

- TermQueryBuilder

- TermsQueryBuilder

입니다.

두 Query 의 큰 차이는 단독으로 사용 되었을 때 Scoring 이 어떻게 되느냐 인데요.

Term 은 Score 계산이 되어서 나오고 Terms 는 Constant Score Query 처럼 1.0 으로 나온다는 것입니다.

코드를 좀 더 따라 가다 보면 

- MapperFieldType

클래스 내 Query API 들에 대한 Interface 나 Implement 코드를 확인해 보실 수 있습니다.

아래는 Terms Query 에 대한 코드를 가져온 내용입니다.

    /** Build a constant-scoring query that matches all values. The default implementation uses a
     * {@link ConstantScoreQuery} around a {@link BooleanQuery} whose {@link Occur#SHOULD} clauses
     * are generated with {@link #termQuery}. */
    public Query termsQuery(Collection<?> values, @Nullable SearchExecutionContext context) {
        BooleanQuery.Builder builder = new BooleanQuery.Builder();
        for (Object value : values) {
            builder.add(termQuery(value, context), Occur.SHOULD);
        }
        return new ConstantScoreQuery(builder.build());
    }

뭐 혼자 기억 하기 위한 기록 이라서 이 정도까지만 기록해 두겠습니다.

알아 보기라고 하기에는 그냥 약간의 예제와 학습 해야 하는 문서 링크 입니다.

https://jmespath.org/specification.html#filter-expressions

$ aws iot list-thing-types --query 'thingTypes[].[thingTypeName, thingTypeName==`1584075120782`]'
$ aws iot list-thing-types --query "thingTypes[].[thingTypeName, starts_with(thingTypeName, '15840')]"

JMES 가 이거 만든 사람 이름의 약어 인것 같은데, 맞는지 모르겠네요.

© Copyright 2014-2015, James Saryerwinnie.

그리고 이 분 AWS 직원인 것 같습니다. :)

안되는 기능입니다.,

참고문서)

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-wildcard-query.html

WildcardQuery 는 사실 추천 하지 않지만 필요에 따라 사용해야 할 수도 있습니다.

성능적으로 좋은 API 는 아니기 때문에 추천 하지 않는 것이지 기능적으로는 유용할 수도 있습니다.

[Field Type]

[Lucene]

[Elasticsearch]

[Usage]

도대체 왜 맨날 잊어버리는지 모르겠지만, 기억력 회복을 위해 기록해 봅니다.

Range query  사용 시 from, to, gt, gte, lt, lte parameter 를 사용 합니다.

RangeQueryBuilder.java 소스코드를 보면 아래와 같이 정의가 되어 있습니다.

private final String name;
private Object from;
private Object to;
private String timeZone;
private boolean includeLower = true;
private boolean includeUpper = true;
private float boost = -1;
private String queryName;
private String format;

기본적으로 lower, upper 값을 포함하게 되어 있습니다.

그러므로, from, to 는 값을 포함 하게 됩니다.

MySQL 에서 제공하고 있는 BETWEEN min AND max 도 min 과 max 값을 포함 하고 있는 것 처럼 동일 합니다.

늘 그렇듯이 기억력의 한계 극복을 위해 기록합니다.

보시면 다들 아시는 내용입니다.

[참고문서]

https://www.elastic.co/guide/en/elasticsearch/reference/2.4/query-dsl-range-query.html

https://www.elastic.co/guide/en/elasticsearch/reference/2.4/mapping-date-format.html

https://www.elastic.co/guide/en/elasticsearch/reference/2.4/date.html

이게 또 언제 변수명이 바뀌었을까요?

버전 릴리즈 될때마다 소스코드를 다 따라 갈수가 없다 보니 이런 오류를 경험하게 되내요.

주의) min_should_match 는 java api 를 이용해서는 사용 할 수 없습니다.

[Terms Query]

OR)

AND)

[Bool Query + Terms Query]

OR)

AND)

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.

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 보다 커야 합니다.