Elasticsearch - 2.검색 API(Elasticsearch Query DSL)

2019. 5. 7. 23:56ㆍSearch-Engine/Elasticsearch&Solr

엘라스틱서치는 인덱스에 저장된 문서를 검색할 수 있도록 다양한 검색기능을 제공한다. 문서는 색인시 설정한 Analyzer에 의해 분석과정을 거쳐 토큰으로 분리되는데, 이러한 Analyzer는 색인 시점 말고도 검색 시점에도 이용된다. 특정 문장이 검색어로 요청되면 분석기를 통해 분석된 토큰의 일치 여부를 판단하여 그 결과에 Score을 매긴다. 이러한 엘라스틱서치에서는 다양한 검색 조건을 주기위하여 Query DSL이라는 특수한 쿼리 문법을 제공한다.

 

1. 검색 API

문장은 색인 시점에 텀으로 분리된다. 검색 시에는 이 텀을 일치시켜야 검색이 가능하다. 엘라스틱서치는 루씬기반이기 때문에 색인 시점에 Analyzer를 통해 분석된 텀을 Term, 출현빈도, 문서번화와 같이 역색인 구조로 만들어 내부적으로 저장한다. 검색 시점에는 Keyword 데이터 타입과 같은 분석이 되지 않는 데이터와 Text 데이터 타입과 같은 분석이 가능한 데이터를 구분해서 분석이 가능할 경우 분석기를 이용해 분석을 수행한다. 이를 통해 검색 시점에도 형태소분석이 되든 되지 않든 텀을 얻을 수 있으며, 해당 텀으로 색인 시점에 생긴 역색인 테이블을 뒤져 문서를 찾고 스코어를 계산하여 결과로 제공한다.

 

1.1. 검색 질의 방식

엘라스틱서치에서 제공하는 검색 API는 기본적으로 Query기반으로 동작한다. 검색 질의에는 검색하고자 하는 각종 Query 조건을 명시할 수 있으며, 동일한 조건을 두 가지 방식으로 표현 가능하다.

 

  1. URI 검색(루씬 스타일)
  2. Request Body 검색

첫번째로 우선 URI방식을 살펴본다. 

 

1.1.1. URI 검색 방식

URI를 이용하는 방식은 HTTP GET 요청을 활용한다. 즉, 쿼리파라미터로 Query를 작성하는 것이다. 간단한 쿼리는 쉽지만 쿼리파라미터의 표현한계로 인해 복잡한 질의는 불가능하다.

 

예시) GET http://localhost:9200/인덱스명/_search?q=필드명:검색값

 

1.1.2. Request Body 검색 방식

Request Body 방식은 HTTP 요청 시 Body에 검색할 칼럼과 검색어를 미리 정의된 JSON 구조로 표현하여 질의하는 방식이다. JSON 구조의 표현을 조금더 효율적으로 하기 위해 엘라스틱서치는 Query DSL이라는 미리 정의된 특별한 문법을 지원한다. URI 검색방식보다 더욱 풍부한 조건의 질의가 가능하다.

 

1
2
3
4
5
6
7
8
9
예시) POST http://localhost:9200/인덱스명/_search
     Header Content-Type:application/json
Request Body {
                "query":{
                   "term":{
                      "typeNm":"장편"
                   }
                }
             }
 cs

 

그러면 각 검색 표현법의 장단점은 무엇일까?

 

1.2.1. URI 검색 방식

URI 검색은 Request Body 검색에 비해 단순하고 사용하기 편하지만 복잡한 질의문을 입력하기 힘들다는 치명적인 단점이 있다. 또한 URI 검색을 이용할 경우에는 엘라스틱서치에서 제공하는 모든 검색 API 옵션을 사용할 수 없다. 이유는 쿼리파라미터 표현법에는 표현상 한계가 있기 때문이다. 하지만 간단한 쿼리 혹은 테스트에서는 간편함을 제공하기도 함으로 URI 검색 방식의 주요 파라미터를 알아보자.

 

파라미터 기본값 설명
q - 검색을 수행할 쿼리 문자열 조건을 지정.
df - 쿼리에 검색을 수행할 필드가 지정되지 않았을 경우 기본값으로 검색할 필드를 지정한다.
analyzer 검색 대상 필드에 설정된 형태소 분석기(색인 시점 분석기) 쿼리 문자열을 형태소 분석할때 사용할 분석기 지정
analyze_wildcard false 접두어/와일드카드 검색 활성화 여부 지정
default_operator OR 두 개 이상의 검색 조건이 q에 포함된 경우 검색 조건 연산자를 설정한다.
_source true 검색 결과에 문서 본문 포함 여부를 지정
sort - 정렬 기준 필드 지정
from - 검색 시작 위치 지정
size - 반환 결과 개수 지정

 

q 옵션에는 기본적으로 '필드명:검색어' 형태로 입력할 수 있으며, 여러개의 필드를 검색 할때는 공백을 입력한 후에 추가적인 필드명과 검색어를 입력한다. URI 검색 방식의 q 옵션은 Request Body 검색에서 제공하는 Query String Search 옵션과 동일하게 동작한다.

 

예시) http://localhost:9200/인덱스명/_search?q=필드명1:필드값1 AND 필드명2:필드값2&

        analyze_wildcard=true&from=0&size=5&sort=_score:desc,필드명:asc&

       _source_includes=필드명,필드명,필드명,필드명

 

 

1.2.2. Request Body 검색 방식

위의 URI 검색방식 예시를 그대로 Request Body 검색 방식으로 바꾸어보겠다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
POST http://localhost:9200/인덱스명/_search
Header Content-Type : application/json
<Request Body>
{
    "query":{
        "query_string":{
            "default_field":"필드명"
            ,"query":"필드명1:필드값1 AND 필드명2:필드값2"
        }
    }
    ,"from":0
    ,"size":5
    ,"sort":[{
        "_score":{
            "order":"desc"
        }
        ,"필드명":{
            "order":"asc"
        }
    }]
    ,"_source":[
        "필드명"
        ,"필드명"
        ,"필드명"
        ,"필드명"
    ]
}
 cs

 

간단한 검색 조건인 경우에는 URI 검색방식이 편해보일 수도 있지만, 구조화된 JSON 구조를 파악하면 더욱 깔끔한 질의작성이 가능하다.

 

 

2. Request Body 검색 방식 - Query DSL 

엘라스틱서치로 검색 질의를 요청할때는 Request Body 방식과 URI 방식 모두 _search API를 이용한다. 하지만 Query DSL 검색을 이용하면 여러개의 질의를 조합하거나 질의 결과에 대해 또 검색을 수행하는 등의 기존 URI 방식 보다 강력한 검색이 가능하다. 엘라스틱서치의 Query DSL은 구조화된 JSON 형태를 사용한다.

 

2.1. Query DSL 구조

 

<요청>

1
2
3
4
5
6
7
8
9
10
{
    "size" : "-->반환받는 결과 개수"
    ,"from" : "-->몇번째 문서부터 가져올지 지정. 기본값은 0이다."
    ,"timeout" : "-->검색 요청시 결과를 받는 데까지 걸리는 시간. timeout을 너무 작게하면
                  전체 샤드에서 timeout을 넘기지 않은 문서만 결과로 출력된다. 기본 값은 무한이다."
    ,"_source" : "-->검색시 필요한 필드만 출력하고 싶을 때 사용"
    ,"query" : "-->검색 조건문이 들어가는 공간"
    ,"aggs" : "-->통계 및 집계 데이터를 사용할때 사용하는 공간"
    ,"sort" : "-->문서 결과의 정렬 조건이 들어가는 공간"
}
 cs

 

엘라스틱서치로 쿼리가 요청되면 해당 쿼리를 파싱해서 문법에 맞는 요청인지 검사한 후에 파싱에 성공하면 해당 쿼리를 기반으로 검색을 수행하고, 결과를 JSON으로 돌려준다.

 

<응답>

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
    "took" : "-->쿼리 실행 시간"
    ,"timed_out" : "-->쿼리 시간이 초과할 경우를 나타낸다"
    ,"_shards" : {
        "total" : "-->쿼리를 요청한 전체 샤드 개수"
        ,"successful" : "-->검색 요청에 성공적으로 응답한 샤드 개수"
        ,"failed" : "-->검색 요청에 실패한 샤드 개수"
    }
    ,"hits" : {
        "total" : "-->질의에 매칭된 문서의 전체 개수"
        ,"max_score" : "-->일치하는 문서의 스코어 값중 가장 높은 값"
        ,"hits" : [결과 문서 정보와 스코어 값등을 보여줌]
    }
}
 cs

 

만약 JSON문법의 오류가 있다면 오류 결과를 JSON으로 넘겨준다.

 

 

2.2. Query DSL 쿼리와 필터

Query DSL을 이용해 검색 질의를 작성할 때 조금만 조건이 복잡해 지더라도 여러개의 질의를 조합해 사용해야 한다. 이때 작성되는 작은 질의들을 두 가지 형태로 나눌 수 있다. 실제 분석기에 의한 전문 분석이 필요한 경우와 단순히 "YES/NO"로 판단할 수 있는 조건 검색의 경우다. 엘라스틱서치에서는 전자를 쿼리 컨텍스트라고 하고, 후자를 필터 컨텍스트라는 용어로 구분한다.

 

  쿼리 컨텍스트 필터 컨텍스트
용도 전문 검색 시 사용 조건 검색 시 사용
특징

1.분석기에 의해 분석이 수행됨.                    2.연관성 관련 점수 계산                              3.루씬 레벨에서 분석 과정을 거처야 하므로 상대적으로 느림.

1.YES/NO로 단순 판별 가능                           2.연관성 관련 점수 계산 안함                         3.엘라스틱서치 레벨에서 처리가 가능하므로 상대적으로 빠름
사용 예 "삼성전자의 본사는 어디있죠?" 같은 문장 분석

"created_year" 필드값이 2018년도인지 여부 "status" 필드에 "user"라는 코드 포함여부

 

대부분의 경우 쿼리 방식과 필터 방식 중 어떤 방식으로 검색 질의를 표현하더라도 같은 결과를 얻을 수도 있다. 하지만 둘의 용도와 성능차이가 있기 때문에 반드시 용도에 맞는 사용을 하는 것이 좋다.

 

2.2.1. 쿼리 컨텍스트

 

  • 문서가 쿼리와 얼마나 유사한지를 점수로 계산
  • 질의가 요청될 때마다 엘라스틱서치에서 내부의 루씬을 이용해 계산을 수행(결과 캐싱 x)
  • 일반적으로 전문 검색에 이용
  • 캐싱되지 않고 디스크 연산을 수행하기에 상대적으로 느림

 

2.2.2. 필터 컨텍스트

 

  • 쿼리의 조건과 문서가 일치하는지를 구분
  • 별도로 점수 계산은 하지 않고 단순 매칭 여부만 검사
  • 자주 사용되는 필터의 결과는 내부적으로 캐싱
  • 기본적으로 메모리 연산이기에 속도 빠름

 

2.3.1. Query DSL 주요 파라미터

 

Multi Index 검색

기본적으로 모든 검색 요청은 Multi Index, Multi Type 검색이 가능하다. 즉, 여러 인덱스를 검색할때 한번의 요청으로 검색요청을 보낼 수 있다. 검색 요청시 ","로 다수의 인덱스명을 입력한다.

 

예시) POST http://localhost:9200/인덱스명1,인덱스명2/_search ...

 

두개의 인덱스명이 공통적인 필드만 갖고 있다면 두개가 서로다른 스키마 구조이더라도 한번에 검색할 수 있다. 검색 요청시 인덱스명에 "*" 입력이 가능하기 때문에 더욱 손쉬운 멀티 인덱스 검색이 가능하다. 예를 들어 매일매일 날짜별로 인덱스를 생성하여 데이터를 색인하는 로그 수집으로 엘라스틱 서치를 이용한다고 생각해보면, "log-2019-01-01" 형태라고 가정시 "log-2019-*"로 손쉽게 멀티 인덱스 검색이 가능하다. 솔라 검색엔진과 비교하면 아주 강력한 기능이다. 보통 솔라는 엘라스틱서치와 달리 인덱스로 도메인을 구분하지 않고 인스턴스로 도메인을 구분하기 때문에 멀티테넌시를 제공하기 쉽지 않다. 그 말은 즉, 도메인 인스턴스별로 같은 질문을 여러번 요청을 보내야 엘라스틱서치의 멀티 인덱스 검색과 같은 결과를 얻을 수 있는 것이다.(최소한 필자 사용시는 그랬음...솔라도 비슷한 기능이 있을 수도 있음)

 

쿼리 결과 페이징

페이징을 하기 위해서는 두가지 파라미터를 이용한다. from과 size이다. 각 기본값은 0,5로 설정되어 있다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
예시) POST http://localhost:9200/인덱스명/_search - 1Page
{
    "from":0,
    "size":5,
    "query":{
        "term":{
            "fieldName":"value"
        }
    }
}
 
예시) POST http://localhost:9200/인덱스명/_search - 2Page
{
    "from":5,
    "size":5,
    "query":{
        "term":{
            "fieldName":"value"
        }
    }
}
 cs

 

엘라스틱서치는 관계형 데이터베이스와는 조금 다르게 페이징된 범위의 문서만 가져오는 것이 아니라, 모든 데이터를 읽고 그 중 필터링하여 몇개의 문서를 가져오는 것이기 때문에 페이지 번호가 높아질수록 쿼리 비용은 비례하여 높아진다.

 

 

쿼리 결과 정렬

엘라스틱서치는 기본적으로 점수를 내림차순으로 결과정렬은 한다. 하지만 점수 이외에 정렬 조건을 주고 싶다면 sort 파라미터를 이용한다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "term":{
            "fieldName":"value"
        }
    }
    ,"sort":{
        "_score":{
            "order":"desc"
        }
        ,"fieldName":{
            "order":"asc"
        }
    }
}
 
 cs

 

위 예제는 점수가 동일할 시에 추가 정렬 조건으로 특정 필드 값으로 오름차순 정렬을 한다.

 

_source 필드 필터링

검색의 결과로 _source의 모든 항목을 결과로 반환한다.(_source의 모든 항목은 문서의 모든 필드를 포함한 결과) 하지만 모든 필드를 결과로 내보낼 필요가 없을 때도 있다. 그때 사용하는 것이 _source 파라미터이다. 필요한 필드만 결과값으로 출력한다면 네트워크 사용량을 줄여 응답 속도도 빨라질 수 있다.

 

1
2
3
4
5
6
7
8
9
10
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "term":{
            "fieldName":"value"
        }
    }
    ,"_source":["fieldName1","fieldName2"]
}
 
 cs

 

범위검색

숫자나 날짜 등을 특정한 숫자나 날짜가 아니라 범위를 지정하여 질의 요청을 할 수도 있다.

 

문법 연산자 설명
lt < 피연산자보다 작음
gt > 피연산자보다 큼
lte <= 피연산자보다 작거나 같음
gte >= 피연산자보다 크거나 같음

 

2016년부터 2019년까지의 데이터 조회 예시이다.

 

1
2
3
4
5
6
7
8
9
10
11
12
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "range":{
            "date":{
                "gte":"2016",
                "lte":"2019"
            }
        }
    }
}
 
 cs

 

 

operator 설정

엘라스틱서치는 검색 시 문장이 들어올 경우 기본적으로 OR연산으로 동작한다. 하지만 실무에서 더 정확도 높은 결과를 위하여 AND연산을 사용하여 검색할때도 있다. 그때 사용하는 것이 operator 파라미터이다.(기본값은 OR이다)

 

1
2
3
4
5
6
7
8
9
10
11
12
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "match":{
            "fieldName":{
                "query":"coding start",
                "operator":"and"
            }
        }
    }
}
 
 cs

 

coding start가 분석기에 의해 분리되고, 두개의 텀을 and 연산으로 검색을 하게 된다. 즉, 둘다 포함된 문서가 결과로 나올 것이다. 만약 OR 연산이라면 coding과 start라는 단어 둘 중 최소한 하나만 포함이 되어도 결과로 반환될 것이다.

 

minimum_should_match 설정

바로 위에서 보았던 operator 설정중 OR연산을 사용하면 너무 많은 결과가 나오게 된다. 이 경우 텀의 개수가 몇 개 이상 매칭될 때만 검색 결과로 나오게 할 수 있는데 이것이 바로 minimum_should_match 파라미터를 이용하는 것이다. 즉, OR연산자로 AND연산과 비슷한 효과를 낼 수 있게 된다.

 

1
2
3
4
5
6
7
8
9
10
11
12
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "match":{
            "fieldName":{
                "query":"this is coding start",
                "minimum_should_match" : 3
            }
        }
    }
}
 
 cs

 

위의 쿼리의 뜻은 OR연산을 사용하되 4개의 텀중 최소한 3개가 일치해야 결과로 내보낸다라는 쿼리이다.

 

 

fuzziness 설정

fuzziness 파라미터를 이용하면 완벽히 동일한 텀으로 문서를 찾는 Match Query를 유사한 텀의 형태로 검색을 하는 Fuzzy Query로 변경할 수 있다. 이는 레벤슈타인 편집 거리 알고리즘을 기반으로 문서의 필드 값을 여러번 변경하는 방식으로 동작한다. 유사한 검색 결과를 찾기 위해 허용 범위의 텀으로 변경해 가며 문서를 찾아 결과로 출력한다. 예를 들어, 편집 거리수를 2로 설정하면 오차범위가 두 글자 이하인 검색 결과까지 포함해서 결과를 준다. 하지만 한국어에는 적용하기 쉽지 않다.(만약 키워드성 질의가 많은 검색이라면 어느정도는 한국어도 가능하기는 한것같다.) 오차범위 값으로 0,1,2,AUTO 총 4가지 값을 사용가능하다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "match":{
            "movieNm":{
                "query":"곤지엠",
                "fuzziness":1
            }
        }
    }
}
 
 
 cs

 

 

위와 같이 질의를 날리면 "곤지암"이라는 영화 제목을 결과값으로 반환받을 수 있다.

 

 

boost 설정

boost 설정으로 관련성이 높은 필드나 키워드에 가중치를 더 줄 수 있게 해준다.

 

1
2
3
4
5
6
7
8
9
10
11
12
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "multi_match":{
            "query":"Fly",
            "fields":["field1^3","field2"]
        }
    }
}
 
 
 
 cs

 

위의 쿼리는 Fly라는 단어가 field1에 있을 경우 해당 문서의 가중치에 곱하기 3을 하여 더 높은 점수를 얻게 된다.

 

 

2.3.2. Query DSL 주요 쿼리

 

Match All Query

match_all 파라미터를 사용하여 색인의 모든 문서를 검색하는 쿼리이다.

 

1
2
3
4
5
6
7
8
9
10
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "match_all":{}
    }
}
 
 
 
 
 cs

 

Match Query

Match Query는 텍스트, 숫자, 날짜 등이 포함된 문장을 형태소 분석을 통해 텀으로 분리한 후 이 텀들을 이용해 검색 질의를 수행한다. 즉, 검색어가 분리돼야 할 경우에 사용해야한다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "match":{
            "fieldName":"coding start"
        }
    }
}
 
 
 
 
 
 cs

 

위의 쿼리는 형태소분석에 의해 coding, start라는 두개의 텀으로 분리되고 별도의 operator가 없기에 OR연산으로 fieldName이라는 필드에 coding,start 텀을 OR연산으로 검색한다.

 

 

Multi Match Query

multi_match 파라미터를 이용하여 하나의 필드가 아니라 여러개의 필드에 대해서 검색을 수행할 수 있다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "multi_match":{
            "query":"가족",
            "fields":["fieldName1","fieldName2"]
        }
    }
}
 
 
 
 
 
 
 cs

 

위에서도 다루어봤지만 multi_match를 사용하면서 특정 필드에 가중치를 부여할 수도 있다.

 

 

Term Query

텍스트 형태의 값을 검색하기 위해 엘라스틱서치는 두 가지 매핑 유형을 지원한다.

 

타입 설명
Text 타입 필드에 데이터가 저장되기 전에 데이터가 Analyzer에 의해 분석되어 역색인 구조로 저장됨.
Keyword 타입 데이터가 분석되지 않고 문장이라도 하나의 텀(분석되지 않은)으로 저장됨

 

바로 이전에 다룬 Match Query는 검색어 매칭 전에 검색 텍스트에 대해 형태소 분석이 들어간다. 하지만 Term Query는 별도의 형태소 분석없이 검색 문자 그대로 해당 문자와 동일한 문서가 있는지 찾는다. 즉, Keyword 데이터 타입을 사용하는 필드를 검색하기 위해서는 Term Query를 사용한다. 그리고 정확히 일치하지 않으면 검색 결과로 나오지 않는다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "term":{
            "fieldName":"코미디"
        }
    }
}
 
 
 
 
 
 
 
 cs

 

fieldsName이라는 필드에 코미디라는 정확한 단어가 포함된 문서가 있다면 결과로 돌려준다.

 

 

Bool Query

RDB에서는 다양하게 AND,OR,NOT 등의 조건을 여러개 WHERE절에 사용할 수 있다. 이처럼 엘라스틱서치도 여러개의 조건 절을 연결하여 더욱 정확한 검색결과를 얻을 수 있는 쿼리가 있는데, 바로 boot query이다. 

 

엘라스틱서치 SQL 설명
must : [] AND 칼럼=조건 반드시 조건에 만족하는 문서만 검색
must_not : [] AND 칼럼!=조건 조건을 만족하지 않는 문서가 검색
should : [] OR 칼럼=조건 여러 조건 중 하나 이상을 만족하는 문서 검색
filter : [] 칼럼 IN (조건) 조건을 포함하고 있는 문서를 출력. 해당 파라미터를 사용하면 점수별로 정렬하지 않는다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "bool":{
            "must":[
                {
                    "term":{
                        "repGenreNm":"코미디"    
                    }
                },
                {
                    "match":{
                        "repNationNm":"한국"
                    }
                }
            ],
            "must_not":[
                {
                    "match":{
                        "typeNm":"단편"
                    }
                }
            ]
        }
    }
}
 
 
 
 
 
 
 
 
 cs

 

해당 쿼리는 장르가 코미디이면서 제작사 나라가 한국이라는 단어를 포함하고 있으며, 종류가 단편이 아닌 영화를 조회하는 쿼리이다.

 

 

Prefix Query

Prefix Query는 해당 접두어가 있는 모든 문서를 검색하는데 사용한다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "prefix":{
            "movieNm":"자전"
        }
    }
}
 
 
 
 
 
 
 
 
 
 cs

 

영화제목에 자전이라고 시작하는 영화 제목을 검색 결과로 모두 가져온다.

 

 

Exists Query

필드 값이 null 인  데이터를 제외하고 검색한다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "exists":{
            "field":"movieNm"
        }
    }
}
 
 
 
 
 
 
 
 
 
 cs

 

Wildcard Query

검색어가 와일드카드와 일치하는 구문을 찾는다. 이때 입력된 검색어는 형태소 분석이 이뤄지지 않는다.

 

와일드카드 옵션 설명
* 문자의 길이와 상관없이 와일드카드와 일치하는 모든 문서를 찾는다
? 지정된 위치의 한 글자가 다른 경우의 문서를 찾는다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
예시) POST http://localhost:9200/인덱스명/_search
{
    "query":{
        "wildcard":{
            "fieldName":"여?"
        }
    }
}
 
 
 
 
 
 
 
 
 
 cs

 

여기까지 간단한 엘라스틱서치 검색 API에 대해 다루어보았다. 다음 포스팅에서는 더 다루지 못한 검색 API 나머지 부분을 다룰 예정이다. 혹시 잘못된 점이나 모르는 점 등이 있다면 댓글을 꼭 부탁드린다..

저작자표시

'Search-Engine > Elasticsearch&Solr' 카테고리의 다른 글

Elasticsearch - 4.한글 형태소분석기(Nori Analyzer)  (6) 2019.05.09
Elasticsearch - 3.부가적인 검색 API  (0) 2019.05.08
ELK - Filebeat 란? (실시간 로그 수집)  (0) 2019.03.20
Solr7.4 Tagger Handler (NER,Named-Entity Recognition)  (0) 2018.09.22
Solr&Zookeeper(솔라&주키퍼) cloud 환경 구성  (1) 2018.09.13

관련글

티스토리툴바