'kibana'에 해당되는 글 11건

web/Spring

Spring Boot에서 6.4 Elasticsearch 연결 및 간단 CRUD

Elasticsearch를 Spring Boot에서 작업을 하는 간단한 정리를 해보자.


1. Library 추가

Elasticsearch를 사용하기 위해서는 spring-data-elasticsearch 라이브러리가 추가되어야 한다. 

gradle에 추가해보자.

1
2
3
4
5
6
7
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-elasticsearch'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    compileOnly "org.projectlombok:lombok:1.16.16"
}
 
cs


spring-data-elasticsearch 버전별로 호환되는 elasticsearch가 상이하니 참고

spring data elasticsearchelasticsearch
3.2.x6.5.0
3.1.x6.2.2
3.0.x5.5.0
2.1.x2.4.0
2.0.x2.2.0
1.3.x1.5.2


2. Configuration

Elasticsearch에 접속하기 위한 Configuration을 정의해준다.

Elasticsearch  접속을 위해서는 host, port, cluster name이 필요하다. cluster name을 알아야 하는데 docker에 설치 한 경우 여기서 확인하면 된다.

우선 docker exec -it elastic bash로 콘솔에 접속한 후에 elasticsearch.yml에 적혀있는 cluster name을 확인한다.

그리고 application.properties에 설정 내용을 적어준다.

1
2
3
4
elasticsearch.host=127.0.0.1
elasticsearch.port=9300
elasticsearch.cluster_name=docker-cluster
spring.main.allow-bean-definition-overriding=true
cs

그리고 EnableElasticsearchRepositories 애노테이션을 설정한 Configuration 클래스를 만들어준다.

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
package com.elasticsearch.study.configuration;
 
import org.springframework.beans.factory.annotation.Value;
import org.elasticsearch.client.Client;
import org.elasticsearch.client.transport.TransportClient;
import org.elasticsearch.common.settings.Settings;
import org.elasticsearch.common.transport.TransportAddress;
import org.elasticsearch.transport.client.PreBuiltTransportClient;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.elasticsearch.core.ElasticsearchOperations;
import org.springframework.data.elasticsearch.core.ElasticsearchTemplate;
import org.springframework.data.elasticsearch.repository.config.EnableElasticsearchRepositories;
 
import java.net.InetAddress;
 
/**
 * Elasticsearch Configuration
 *
 * @author wedul
 * @since 2019-02-09
 **/
@EnableElasticsearchRepositories
@Configuration
public class ElasticConfiguration {
 
  @Value("${elasticsearch.host}")
  private String host;
 
  @Value("${elasticsearch.port}")
  private int port;
 
  @Value("${elasticsearch.cluster_name")
  private String clusterName;
 
  @Bean
  public Client client() throws Exception {
    Settings settings = Settings.builder().put("cluster.name", clusterName).build();
 
    TransportClient client = new PreBuiltTransportClient(settings);
    client.addTransportAddress(new TransportAddress(InetAddress.getByName(host), port));
    return client;
  }
 
  @Bean
  public ElasticsearchOperations elasticsearchTemplate() throws Exception {
    return new ElasticsearchTemplate(client());
  }
 
}
 
cs


3. DTO 생성

Elasticsearch에서 Document 내용을 담을 DTO를 만들어주고 @Document 애노테이션을 달고 index name과 type을 정의해준다.

@Id 어노테이션이 붙은 필드는 각 Doucument에 붙어있는 _id 값이다.

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
package com.elasticsearch.study.dto;
 
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.ToString;
import org.springframework.data.annotation.Id;
import org.springframework.data.elasticsearch.annotations.Document;
 
/**
 * studyFor
 *
 * @author wedul
 * @since 2019-02-09
 **/
@Data
@AllArgsConstructor
@NoArgsConstructor
@ToString
@Document(indexName = "wedul_play", type = "story")
public class WedulPlay {
 
  @Id
  private String id;
  private String title;
  private String user;
  private long startAt;
  private long endAt;
 
}
 
cs


4. Repository

JPA를 사용하면 익숙할 패턴으로 Elasticsearch에서도 ElasticsearchRepository가 존재한다. 사용방법은 JPA와 동일하게 저장할 때는 save, 조회할 때는 find(), findByUser()등으로 사용할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
package com.elasticsearch.study.repository;
 
import com.elasticsearch.study.dto.WedulPlay;
import org.springframework.data.elasticsearch.repository.ElasticsearchRepository;
import org.springframework.stereotype.Repository;
 
/**
 * study
 *
 * @author wedul
 * @since 2019-02-09
 **/
@Repository("wedulPlayRepository")
public interface WedulPlayRepository extends ElasticsearchRepository<WedulPlay, String> {
 
  WedulPlay findByUser(String user);
  
}
 
cs


5. Service

지금 테스트 하는 부분에서는 크게 비즈니스 로직에 들어갈 소스가 없다.

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
35
36
37
38
package com.elasticsearch.study.service;
 
import com.elasticsearch.study.dto.WedulPlay;
import com.elasticsearch.study.repository.WedulPlayRepository;
import com.google.common.collect.Lists;
import lombok.AllArgsConstructor;
import lombok.NoArgsConstructor;
import org.springframework.stereotype.Service;
 
import java.util.List;
 
/**
 * study
 *
 * @author wedul
 * @since 2019-02-09
 **/
@AllArgsConstructor
@NoArgsConstructor
@Service
public class WedulPlayService {
 
  private WedulPlayRepository wedulPlayRepository;
 
  public void save(WedulPlay play) {
    wedulPlayRepository.save(play);
  }
 
  public List<WedulPlay> findAll() {
    return Lists.newArrayList(wedulPlayRepository.findAll());
  }
 
  public WedulPlay findByUser(String user) {
    return wedulPlayRepository.findByUser(user);
  }
 
}
 
cs


6. Test 코드

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
package com.elasticsearch.study.wedulplay;
 
import com.elasticsearch.study.dto.WedulPlay;
import com.elasticsearch.study.repository.WedulPlayRepository;
import com.elasticsearch.study.service.WedulPlayService;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;
 
import java.util.List;
 
import org.hamcrest.core.IsNull;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.*;
 
/**
 * wedul play document 조회
 *
 * @author wedul
 * @since 2019-02-09
 **/
@RunWith(SpringRunner.class)
@SpringBootTest
public class WedulPlayTest {
 
  WedulPlayService wedulPlayService;
 
  @Autowired
  @Qualifier("wedulPlayRepository")
  WedulPlayRepository wedulPlayRepository;
 
  @Before
  public void setup() {
    wedulPlayService = new WedulPlayService(wedulPlayRepository);
  }
 
  @Test
  public void whenValidParameter_thenSuccessFind() {
    List<WedulPlay> list = wedulPlayService.findAll();
 
    assertNotNull(list);
  }
 
  @Test
  public void whenValidParameter_thenSuccessSave() {
    Exception ex = null;
 
    try {
      wedulPlayService.save(WedulPlay.builder().title("안녕 이건 테스트야").user("위들").startAt(1242421424).endAt(23214124).build());
    } catch (Exception exception) {
      ex = exception;
    }
 
    assertTrue(null == ex);
  }
 
  @Test
  public void whenValidParameter_thenSuccessFindByUser() {
    Exception ex = null;
 
    try {
      WedulPlay play = wedulPlayService.findByUser("위들");
 
      assertThat(play, is(IsNull.notNullValue()));
    } catch (Exception exception) {
      ex = exception;
    }
 
    assertTrue(null == ex);
  }
 
 
}
 
cs


설정이 간단하다. 

나중에 이용해 먹어야지


자세한 소스코드는 여기 참조

https://github.com/weduls/spring_elastic

데이터베이스/Elasticsearch

docker logstash 설치 및 log 파일 elasticsearch에 기록

ELK에서 logstash를 제외하고는 모두 경험해봤다.

이제 logstash를 사용해서 log파일을 elasticsearch에 기록해보자.


설치

elasticseach도 kibana도 pc에 직접 설치하고 싶지 않아서 docker에 설치해서 사용했다. logstash도 docker에 설치해서 사용해보자.


물론 logstash를 사용하기전에 elasticseach와 kibana가 설치되어 있어야한다. 설치법은 저번 게시물에 올려놨다.


logstash를 이름을 지정해서 background에서 동작하도록 실행시킨다.

1
docker run --name logstash -d docker.elastic.co/logstash/logstash:6.4.0
cs


설정파일

logstash를 설치하면 내부에 다음과 같은 설정파일이 존재한다.

 이름

 설명

logstash.yml 

 logstash 구성 플래그가 들어있다. 이곳에 설정하면 command에 직접 설정할 필요가 없다. 그래도 command명령이 logstash.yml 파일의 우선순위보다 높다.

 pipelines.yml

 single logstash 인스턴스에서 파이프라인을 실행시키기 위한 설정내용을 담고 있다. input, filter, output등을 설정한다,

 jvm.options

 jvm 설정을 포함하고 있어서 힙사이즈 조절이 가능하다.

 log4j2.properties

log4j 설정을 할 수있다. 


설치가 완료된 후 logstash를 기존에 설치된 elasticsearch에 연동해서 상태를 보려고 할때 오류가 발생한다. config/logstash.yml에서 호스트 네임을 설정해주면 정상적으로 연결이 되고 monitoring까지 할 수 있다.



파이프라인

logstash에서 파이프라인은 input, output, filter가 존재한다. input과 output은 데이터 입출력을 위해 필수값이고 filter는 정재하기 위한 설정으로 선택값이다.

파이프라인 설정은 /pipieline 내부에 conf파일을 생성하여 설정할 수있다.


로그기록

그럼 설치된 logstash에서 특정 로그파일을 읽어서 elasticsearch에 기록해보자. pipeline.yml 파일을 수정해서 다음과 같이 기록한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
input {
  file {
    path => "/wedul.log"
    start_position => "beginning"
    sincedb_path => "/dev/null"
  }
}
 
output {
  elasticsearch {
    hosts => "http://we.local:9200"
    index=>"wedulpos"
  }
}
cs


위 내용은 파일을 읽고 elasticsearch wedulpos인덱스에 저장하라는 내용이다. start_position이 beginning이면 처음부터 읽으라는 것이고 sincedb는 내부적으로 어디까지 읽었는지 확인하기위해 저장하는 db이다. 현재 테스트할때 sincedb 설정이 제대로 되지 않아 No sincedb_path set, generating one based on the "path" setting 오류가 발생하여 우선적으로 /dev/null로 진행했다.

설정이 끝나고 logstash를 실행시키면 다음과 같이 저장되는걸 알 수있다.


모니터링에서도 해당 로그 기록 상황을 볼 수있다.


이 밖에도 input, output을 jdbc, cloudwatch등으로 설정해서 진행할수도 있다.




데이터베이스/Elasticsearch

Elasticsearch에서 refresh 정리

Elasticsearch에서 document를 업데이트하고 바로 해당 정보를 조회하려고 했다.

하지만 조회가 되지 않았다. 분명이 업데이트가 종료된 것을 확인 했는데 왜 그런지 의문이 들었다.


그래서 찾아봤는데 document가 업데이트가 되고나서 인덱스에서 실제로 조회가 될 수있는 상태가 되기위해서는 일정시간이 필요한 것 같다.

자세히는 모르지만 다시 인덱싱을 걸기 때문에 그러는건 아닌가 생각된다.


그래서 이런경우에 업데이트가 종료 되었다고 알리는 시간을 검색이 가능하게 변경된 시간까지 포함해서 알려주도록 하는 옵션이 존재한다.


그렇게 되면 업데이트가 되고 검색이 가능한줄 알고 프로그램을 작성하다가 버그가 발생하는 비율을 줄일 수 있다.


일반적인 bulkInsert나 update, create같은 명령에는 refresh: wait_for를 사용하고 update by query 등에 명령어에서는 waitForCompletion=true 옵션을 부여하여 검색을 사용한다.


예시

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
client.bulk({
refresh: wait_for,
  body: [
    // action description
    { index:  { _index: 'myindex', _type: 'mytype', _id: 1 } },
     // the document to index
    { title: 'foo' },
    // action description
    { update: { _index: 'myindex', _type: 'mytype', _id: 2 } },
    // the document to update
    { doc: { title: 'foo' } },
    // action description
    { delete: { _index: 'myindex', _type: 'mytype', _id: 3 } },
    // no document needed for this delete
  ]
}, function (err, resp) {
  // ...
});
cs

api 문서를 보면 조금 더 정확한 내용을 확인할 수 있다.


참고

https://stackoverflow.com/questions/40676324/elasticsearch-updates-are-not-immediate-how-do-you-wait-for-elasticsearch-to-fi

https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current/api-reference.html



주의

하지만 이렇게 프로그램을 작성할 경우에는 예상하는 바와 같이 엄청난 시간이 소요된다.

실제로 이번에 프로젝트를 진행할 때 해당 옵션없이 업데이트를 할 때 5분걸렸던 양이 1시간이 되어도 되지 않았다. 이럴 경우에는 하나하나 다 update 명령을 사용하지말고 bulk로 작업하는 것을 추천한다. 훨씬빠르다.



데이터베이스/Elasticsearch

Elasticsearch에서 search_after 기능 사용하여 조회하기

elasticsearch에서 search_after를 이용하여 데이터를 조회하는 방법을 정리해보자.

우선 사용할 인덱스를 생성하자.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
PUT wedul
{
  "mappings": {
    "cjung": {
      "properties": {
        "id": {
          "type": "keyword"
        },
        "name": {
          "type": "text",
          "analyzer": "nori",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        }
      }
    }
  }
}
cs


생성된 인덱스에 데이터 몇개만 삽입하여보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
POST wedul/cjung?pretty { "id": "wemakeprice", "name": "원더쇼핑" } POST wedul/cjung { "id": "dauns", "name": "다운" }
cs


그리고 일반적으로 사용하는 방식으로 데이터를 조회해보자.

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
GET wedul/cjung/_search
{
  "from": 0, 
  "size": 2, 
  "query": {
    "match_all": {}
  }
}
 
 
{
  "took" : 8,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 3,
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "wedul",
        "_type" : "cjung",
        "_id" : "_update",
        "_score" : 1.0,
        "_source" : {
          "doc" : {
            "id" : "wedul",
            "name" : "정철"
          }
        }
      },
      {
        "_index" : "wedul",
        "_type" : "cjung",
        "_id" : "tSNYH2cBvWxWFgHQJ6J4",
        "_score" : 1.0,
        "_source" : {
          "doc" : {
            "id" : "dauns",
            "name" : "다운"
          }
        }
      }
    ]
  }
}
 
cs

정상적으로 조회가 된다. 하지만 여기서 만약 size가 10000이 넘은 곳을 검색하고 싶다면 어떻게 될까? 저번에 공부해서 정리한 글 처럼 10000개 이상에 데이터에 접근하려고 하면 오류가 발생한다.

참고 : https://wedul.tistory.com/518?category=680504


그럼 어떻게 조회해야 할까? 그래서 제공되는 방법이 search_after를 이용하여 검색하는 방법이다.

search_after는 라이브 커서를 제공하여 다음 페이지를 계속 조회하는 방식으로 검색기능을 제공한다. 


기본적인 검색 방법은 다음과 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
GET wedul/cjung/_search
{
  "sort": [
    {
      "id": {
        "order": "asc"
      },"name.keyword": {
        "order": "desc"
      }
    }
  ], 
  "size": 1, 
  "query": {
    "match_all": {}
  }
}
cs


이렇게 검색을하게 되면 다음과 같이 결과가 나오는데 여기서 나온 sort  필드를 이용하여 다음 필드를 조회해 나가는 것이 search_after 기능이다.

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
{
  "took" : 9,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : null,
    "hits" : [
      {
        "_index" : "wedul",
        "_type" : "cjung",
        "_id" : "uyNoH2cBvWxWFgHQ86L9",
        "_score" : null,
        "_source" : {
          "id" : "wemakeprice",
          "name" : "원더쇼핑"
        },
        "sort" : [
          "wemakeprice",
          "원더쇼핑"
        ]
      }
    ]
  }
}
 
cs


위에 나온 검색결과 sort에 출력된 wemakeprice와 원더쇼핑을 사용하여 다음 데이터를 조회한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
GET wedul/cjung/_search
{
  "search_after": ["wemakeprice",
          "원더쇼핑"],
  "sort": [
    {
      "id": {
        "order": "asc"
      },"name.keyword": {
        "order": "desc"
      }
    }
  ], 
  "query": {
    "match_all": {}
  }
}
cs


그렇다면 저 위에 sort 필드는 과연 무엇인가 하고 생각이 들 수 있다. sort 필드는 바로 검색 dsl에서 사용했던 sort필드의 값 들이다. 이 값 다음에 나오는 데이터를 조회 하라는 뜻이다. 그렇기 때문에 무조건 search_after를 사용하기 위해서는 데이터를 정렬하는것이 필수이다. 그리고 정말 중요한 것은 그 sort필드에 들어가는 데이터중 하나는 무조건 unique한 값 이어야 한다는 것이다. 그렇지 않으면 어디서 부터 검색을 시작해야할지 알지 못하기 때문이다. 


참고

https://www.elastic.co/guide/en/elasticsearch/reference/master/search-request-search-after.html

데이터베이스/Elasticsearch

Elasticsearch에서 Full text queries와 Term level queries 정리

Elasticsearch를 사용하다보면 term과 match 관련된 쿼리에 대해 헷갈리는 경우가 많다. Document에 있는 내용을 가져와서 정리해보자.


Full text queries

The high-level full text queries are usually used for running full text queries on full text fields like the body of an email. They understand how the field being queried is analyzed and will apply each field’sanalyzer (or search_analyzer) to the query string before executing.


match query

The standard query for performing full text queries, including fuzzy matching and phrase or proximity queries.

-> 전체 텍스트 쿼리를 수행하기 위한 기본 쿼리 (fuzzy 매치와 phrase, 근접 쿼리를 포함). 쉽게 말해 전체 텍스트에서 특정 부분이 포함되는지 여부를 확인하는데 fuzzy를 이용하여 유사도가 어느정도 되는 쿼리들도 조회 가능


match_phrase query

Like the match query but used for matching exact phrases or word proximity matches.

-> match와 같지만 정확한 구문이나 근접하게 매치되는 단어를 찾기위해 사용되는 쿼리


match_phrase_prefix query

The poor man’s search-as-you-type. Like the match_phrase query, but does a wildcard search on the final word.

-> match_phrase와 유사하지만 마지막 단어에서 와일드카드 사용됨. (자동완성 기능에서 자주 실행 됨)


multi_match query

The multi-field version of the match query.

-> match 쿼리의 다중 필드 버전


common terms query

A more specialized query which gives more preference to uncommon words.

-> Documentd에서 자주 발생되는 단어를 제외하고 진짜 의미있는 단어만 검색하기 위해서 사용될 때 사용하는 쿼리

-> cutoff_frequency 옵션을 사용해서 0.1%보다 빈도수가 많은 단어는 제외하고 검색하라고 할 수 있다.

"query": { "common": { "body": { "query": "this is bonsai cool", "cutoff_frequency": 0.001 } } }


query_string query

Supports the compact Lucene query string syntax, allowing you to specify AND|OR|NOT conditions and multi-field search within a single query string. For expert users only.

-> 컴팩트 한 Lucene 쿼리 문자열 구문을 지원하므로 단일 쿼리 문자열 내에서 AND | OR NOT 조건과 다중 필드 검색을 지정할 수 있습니다.

-> 검색이 실행될 필드를 지정하고 쿼리에 사용된 AND|OR|NOT 조건에 사용된 값들은 독립적으로 텍스트를 분석해서 결과를 도출한다.

-> 단 Lucene 파서를 사용하기 때문에 reserved character가 들어간 경우 검색이 안되니 반드시 \\ 이것을 붙혀서 escape 처리를 해줘야 한다.

"query": {
    "query_string" : {
        "default_field" : "content",
        "query" : "this AND that OR thus"
    }
}


simple_query_string query

A simpler, more robust version of the query_string syntax suitable for exposing directly to users.

-> query_string을 더 간단하게 사용할 수 있도록 제공된 쿼리




Term level queries

While the full text queries will analyze the query string before executing, the term-level queriesoperate on the exact terms that are stored in the inverted index, and will normalize terms before executing only for keyword fields with normalizer property.

These queries are usually used for structured data like numbers, dates, and enums, rather than full text fields. Alternatively, they allow you to craft low-level queries, foregoing the analysis process.


term query

Find documents which contain the exact term specified in the field specified.

-> 검색하고자 하는 필드에 정확한 텀을 포함하고 있는지 확인하는 쿼리


terms query

Find documents which contain any of the exact terms specified in the field specified.

-> 검색하고자 하는 필드에서 정확한 텀들을 포함하고 있는지 확인하는 쿼리


terms_set query

Find documents which match with one or more of the specified terms. The number of terms that must match depend on the specified minimum should match field or script.

-> 지정된 용어 중 하나 이상과 일치하는 문서를 찾는다. 지정된 최소값과 일치해야하는 용어의 수는 필드 또는 스크립트와 일치해야 한다.

"query": {
    "terms_set": {
        "codes" : {
            "terms" : ["abc", "def", "ghi"],
            "minimum_should_match_field": "required_matches"
        }
    }
}


range query

Find documents where the field specified contains values (dates, numbers, or strings) in the range specified.

-> 검색하고자 하는 필드에서 입력한 범위에 포함되는 날짜나, 숫자, 문자열등을 검색할 때 사용.


exists query

Find documents where the field specified contains any non-null value.

-> 검색하고자 하는 필드에 값이 있는지 여부 확인


prefix query

Find documents where the field specified contains terms which begin with the exact prefix specified.

->검색하고자 하는 필드에서 입력한 값으로 시작하는 문장이 있는지 검색할 때 사용


wildcard query

Find documents where the field specified contains terms which match the pattern specified, where the pattern supports single character wildcards (?) and multi-character wildcards (*)

-> 와이드카드 *, ?를 사용해서 검색하는 방법. 전체를 다 뒤져서 찾아야하기 때문에 성능에 아주 안좋은 결과를 초래한다.


regexp query

Find documents where the field specified contains terms which match the regular expression specified.

-> 정규식을 이용해서 정확한 문장 찾기


fuzzy query

Find documents where the field specified contains terms which are fuzzily similar to the specified term. Fuzziness is measured as a Levenshtein edit distance of 1 or 2.

-> 입력한 term과 비슷한 문자를 찾을 때 사용하는 쿼리 레벤스테인 거리 알고리즘을 사용하고 설정한 거리에 따라서 어느정도 유사도에 값을 찾을지 정할 수 있다.


type query

Find documents of the specified type.

-> 입력한 타입에 맞는 값을 찾는 쿼리

"query": {
    "query_string" : {
        "default_field" : "content",
        "query" : "this AND that OR thus"
    }
}


ids query

Find documents with the specified type and IDs.

-> 타입과 IDS를 가진 값을 찾는 쿼리

"query": {
    "ids" : {
        "type" : "_doc",
        "values" : ["1", "4", "100"]
    }
}












match_phrase와 term의 차이 참고 사이트

https://findstar.pe.kr/2018/01/19/understanding-query-on-elasticsearch/

 [ 1 ]  [ 2 ]  [ 3 ] 

푸터바

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

  • Today : 36
  • Yesterday : 651
  • Total : 55,511