[번역] Elasticsearch 퍼포먼스 튜닝 방법 - ebay

Elasticsearch에 대해 검색하다가 ebay에 퍼포먼스 튜닝방법에 대해 좋은 글이 있어서 간단하게 정리해봤다. 새롭게 알게된 사실이 많아서 좋았다. 

정리 잘된 기술 블로그를 보는것은 책을 읽는거보다 훨씬 유익한 경우가 많은 것 같다.

 

Elasticsearch


엘라스틱 서치는 아파치 루씬을 기반으로한 검색과 분석 엔진으로 데이터를 실시간에 가깝게 보여주고 분석해 준다. 실시간성으로 분석과 검색을 위해서 많이 사용되는 엘라스틱 서치의 퍼포먼스는 무엇보다 중요한데 이를 위한 퍼포먼스 튜닝방법을 정리해보자.

높은 엘라스틱서치의 퍼포먼스를 위해서는 많은 처리량, 낮은 검색 지연시간등이 요구된다.

 

고효율성 Elasticsearch를 위한 솔루션


- 효율 적인 인덱스 디자인
인덱스를 설계하다보면 하나의 인덱스에 모든 데이터를 넣고 쿼리로 찾을것인지 아니면 여러 인덱스로 나눌것인지 고민된다. 어느것이 효율적이냐는 정답은 내가 사용하는 쿼리에 달려있다. 유형별로 사례를 보면서 확인해보자.

1. 쿼리에 filter가 들어가고 그 값이 Enumerable할 때는 인덱스를 나눠서 설계하라
만약 인덱스 내부에 데이터에서 지역별로 나눠서 데이터를 찾아야 한다면 다음과 같이 쿼리를 실행시킬 것이다. 이럴경우 지역별로 인덱스를 구분하여 만들면 더욱 효율적인 퍼포먼스를 기대할 수 있다.

{
    "query": {
        "bool": {
            "must": {
                "match": {
                    "title": "${title}"
                }
            },
            "filter": {
                "term": {
                    "region": "US"
                }
            }
        }
    }
}

 

2. 값이 enumerable하지 않다면 routing key를 사용하라.
만약 수백만개의 주문 데이터가 구매자별로 쌓인다고 가졍하였을때 구매자별로 인덱스를 구분한다면 너무 많은 인덱스를 구분해야한다. filter 사용되는 필드를 routing key로 사용하여 인덱스를 여러 shard로 쪼갤 수 있다. 그래서 이럴 경우 동일한 buyerId를 가지고 있는 데이터를 동일한 shard에 모여서 저장하면 모든 쿼리가 buyerId라는 routing key를 사용하여 한번에 조회되게 하면 퍼포먼스가 향상된다.

3. 기간이 정해져 있는 데이터들의 경우 기간별로 인덱스를 구성하여 사용하라.
로깅, 모니터링을 하는 데이터의 경우 일, 주, 월별로 데이터를 모을 수 있기 때문에 이를 사용하여 날짜별로 데이터를 모으면 더 빠르게 데이터에 접근할 수 있다.

4. mapping을 효율적으로 지정하라
인덱스에서 필드별로 mapping을 지정해줘야 해당 필드에 대한 검색이 가능하다. 기본적으로 데이터가 인덱스에 들어가면 기본적으로 자동 매핑을 해주지만 효율적이지는 않다. 그래서 정상적으로 인덱스에 맞게 효율적으로 인덱스를 설계하고 index생성시 dynamic옵션을 false로 지정하여 자동 매핑을 방지하는게 좋다. 자동매핑에 경우 문자열을 text, keyword모두 지정해주는데 이는 그닥 효율적이지 못한 대표적인 예이다.

5. 사용자 정의 id를 사용할 경우 불균형 샤딩에 대해 조심하라.
엘라스틱 서치는 자동으로 id를 생성해주는데 이를 호ㄹ용하여 적절하게 document들에 대하여 샤딩을 수행한다. 만약 사용자 지정 id를 사용하거나 별도의 routing key를 충분히 랜덤하지 않게 부여한다면 다른 shard들에 비해 특정 shard가 데이터가 많이 적재되는 문제를 초래할 수 있다. 이럴 경우 일기/쓰기가 굉장히 느려지게 되기 때문에 조심해야한다.

6. 여러 노드에 고르게 shard를 만들어라.
엘라스틱서치에는 coordinator node와 여러 마스터 노드들로 구성되어 있는데 coordinator 노드는 분배 역할을 주로 담당하고 master node들이 데이터 적재를 담당하는데 각 특정노드에 shard가 몰려있을 경우 전체 시스템의 bottle neck 현상이 발생할 수 있다.


7. bulk request를 높이고 refresh 기간을 올려라.
이벤트가 발생할 때마다 엘라스틱서치는 새로운 lucene segment를 만들고 그것을 추후에 합치는 작업을 진행한다. 이런 작업이 발생하는 주기가 refresh가 발생할 때 진행되는데 이런 문제를 줄이기 위해서는 refresh interval을 길게 잡아 놓으면 좋다. 하지만 refresh interval이 길면 변경된 데이터가 검색이 되지 않는다. 왜냐면 index가 refresh가 종료되어야 변경되거나 추가된 document가 검색에 잡히기 때문이다.


8. replica 수를 줄여라.
엘라스틱서치 노드는 주요 노드에 기록되고 모든 replica shard들에 인덱싱 요청이 발생된다. 그렇기 때문에 replica shard수가 많을수록 document의 인덱싱 속도가 현저하게 느려진다.


9. 가능하면 자동으로 생성되는 ID를 사용하라.
엘라스틱서치에서 만들어주는 ID는 고유값을 보증한다. 만약 사용자 고유 ID를 진행하고 싶은 경우 루신에 친화적인 zero-paddeded sequaltial 아이디인 UUID-1 또는 Nono time을 사용해야 한다. 이 아이디들은 일관되고 연속적인 패턴이 잘 압축되어 있는 형식들이다. 대조적으로 UUID-4는 완전하게 랜덤한값을 만들어내기 때문에 추천하지 않는다.


10. 가능하면 query context에 filter를 사용해라.
쿼리에서 찾고자 하는 값과 일치하는 걸 찾을 때 대부분인 yes or no로 찾을 수 있다. match등을 통해서 데이터를 찾으면 scoring이 들어가기 때문에 더 성능적으로 힘들어진다. 하지만 filter를 사용하면 결과가 캐시가 되는것뿐만 아니라 단순 yes or no이기 때문에 score 계산이 빠져서 더 효율적이다.


11. shard 노드를 효율적으로 관리하라
인덱스에 어느정도에 shard를 설정해야할까가 인덱스 구축시 고민을 많이 하게되는 요소이다. 불행하게도 모든 시나리오에 정확한 정답은 없다. 모든것은 어떻게 설계하냐에 따라 달려있다. 만약 너무 작은 수의 shard를 설정하게 되면 scale out이 되지 않는다. 예를들어 오직 하나의 shard만 있는 경우 모든 도큐먼트는 한곳에 저장되서 문제가 발생한다. 반대로 너무 많은 shard를 설정하게 되면 퍼포먼스에 문제가 발생한다. 왜냐하면 엘라스틱서치는 모든 shard에 쿼리를 실행시키기 때문에 request안에 routing key가 있다고 하더라도 fetch 그리고 merge가 모든 shard에서 나온 결과에서 발생하기 때문이다. 여러 관례로 봤을 때, 만약 index가 1G가보다 작으면 shard는 1개가 적당하다. 대부분에 경험상 shard를 5섯개를 기본으로 놓고 운영하는게 적당했다. 하지만 shard사이즈가 30GB가 넘으면 더 쪼개서 사용해야한다. 한번 생성된 index에 shard수를 조정하려면 reindex를 해야하므로 신중하길 바란다.


12. stop word를 사용한 검색을 자제하라
stop word는 a, the와 같이 검색 결과를 증가시키는 단어들이다. 만약 fox라고 검색하면 10건나올 데이터가 the fox라고 하면 the와 가까운 데이터가 출력되면서 거의 대부분의 document가 출력될 것이다. 엘라스틱서치는 모든결과를 score별로 정렬하기 때문에 the fox와 같이 stop word로 검색하면 전체 시스템을 느리게 만든다. 미리 token filter를 만들어서 stop word를 제거하고 검색되게 만드는게 효율적이다. 만약 당장 어렵다면 the ADN fox라고 검색해서 중요한 결과만을 뽑아낼 수 있다.

 

오랜만에 좋은글 잘 읽어서 기분이 좋다. 

출처 : https://www.ebayinc.com/stories/blogs/tech/elasticsearch-performance-tuning-practice-at-ebay/

댓글()
  1. wedul 2019.08.13 18:11 댓글주소  수정/삭제  댓글쓰기

    shard는 데이터 자체를 의미하고 replica shard는 백업을 위한 shard가 아니라 failover를 위한 shard이기 때문에 replica shard를 많이 설정하는건 안좋다.

Elasticsearch template를 일별 index 구성하기

Elasticsearch를 이용해서 로그기록을 많이한다. 일별 로그성 인덱스를 자동으로 만들기 위해 template를 사용해서 구성하는 법을 정리해보자.

우선 매일 새롭게 생성될 index에 대한 template를 생성해보자.

template 생성


PUT _template/wedul_log_*
{
  "index_patterns": [
    "wedul_log_*"
  ],
  "mappings": {
    "_doc": {
      "dynamic": false,
      "properties": {
        "id": {
          "type": "integer"
        }
      }
    }
  }
}

생성한 템플릿이 잘 만들어졌는지 확인해보자.

확인
GET template/wedul_log*

그럼 이제 wedul_log라는 대표 인덱스를 생성해주고 template에 맞는 일자별 인덱스를 만들어보자.

PUT wedul_log
{
  "mappings": {
    "_doc": {
      "dynamic": false,
      "properties": {
        "id": {
          "type": "integer"
        }
      }
    }
  }
}

인덱스 생성이 완료되면 template에 맞게 데이터를 삽입해보자.

일별 데이터 추가

POST wedul_log_2019.06.12/_doc
{
	"id": 1
}

POST wedul_log_2019.06.13/_doc
{
	"id": 2
}

6월 12, 13일에 대한 로그 인덱스가 생겼고 document가 생성되었다.

이런식으로 일자별 인덱스를 자동으로 생성하게 할 수 있다.

여러 로그성 인덱스를 한번에 조회를 다음 명령어를 통해 할 수 있다.

GET wedul_log_2019.06.12,wedul_log_2019.06.13/_search

댓글()

Elasticsearch에서 reindex를 이용해서 매핑정보 변경하기

Elasticsearch에서 index를 구성하다보면 매핑정보를 추가하거나 수정하고 싶을때가 있다.  내가 아는 내에서는 한번 생성된 index의 매핑정보를 변경하는건 어렵다. 그래서 reindex를 통해 index의 매핑정보를 변경해줘야한다.

우선 wedul_mapping이라는 인덱스가 있다고 해보자.
매핑 정보는 다음과 같다.

PUT wedul_mapping
{
  "mappings": {
    "_doc": {
      "dynamic": "false",
      "properties": {
        "id": {
          "type": "integer"
        },
        "name": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword"
            }
          }
        }
      }
    }
  }
}

이때 name에서 keyword필드를 제거하고 age라는 새로운 Integer타입의 필드를 매핑하고 싶은 경우에 wedul_mapping_dump라는 새로운 임시 인덱스를 생성한다.

PUT wedul_mapping_dump
{
  "mappings": {
    "_doc": {
      "dynamic": "false",
      "properties": {
        "id": {
          "type": "integer"
        },
        "name": {
          "type": "text"
        },
        "age": {
          "type": "integer"
        }
      }
    }
  }
}

그리고 기존 wedul_mapping인데스에서 wedul_mapping_dump 인덱스로 reindex를 실행한다.

POST _reindex
{
  "source": {
    "index": "wedul_mapping"
  },
  "dest": {
    "index": "wedul_mapping_dump"
  }
}

 

그럼 데이터가 모두 변경된 인덱스 wedul_mapping_dump로 복사되면서 매핑정보가 변경된것을 알 수 있다. 그리고 이름이 같은 wedul_mapping인덱스에 다시 옮기려면 wedul_mapping인덱스를 제거하고 변경된 매핑정보로 새로 생성한뒤 다시한번 reindex를 해주면된다. 데이터가 많은 실 환경에서는 reindex 작업의 비용이 크기 때문에 한번 매핑정보를 설정할 때 잘해주는것이 좋을 것 같다.

댓글()

Elasticsearch에서 synonyms.txt로 동의어 필터 만들어서 사용하기

elasticsearch에서 검색기능을 넣다가 2080이라는 키워드를 검색 했을때와 이공팔공이라는 검색어를 입력했을 때 두개 모두 동일한 데이터를 출력하도록 지정하고 싶었다.

그래서 synonyms 필터를 만들기로 했다.

우선 synonyms 필터를 만들어서 사용하기 위해서는 동의어에 대한 정리가 되어있는 사전을 만들어야 한다.

사전 생성 방법은 다음과 같고 아래 링크를 참조해서 간단하게 사전을 만들었다.
https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-synonym-tokenfilter.html

파일명은 synonyms.txt이고 내용은 다음과 같다.

synonyms.txt

노레바,noreva,노래바
airpods,에어팟,airpod,airpot
2080,이공팔공

 

동의어 정리 사전을 elasticsearch에 넣어줘야하고 경로는 다음과 같다.

/usr/share/elasticsearch/config/analysis



나는 docker를 사용하기 때문에 생성한 파일을 다음 명령어를 통해 위치시켰다.

docker cp synonyms.txt elastic6.4:/usr/share/elasticsearch/config/analysis



그럼 이 필터를 사용하기 위해서 인덱스를 만들 때 설정을 달아서 추가해주자.
간단하게 keyword 하나만 존재하는 인덱스를 만들고 synonyms filter를 사용하게 해보자

여기서 사용하 tokenizer는 nori_tokenizer를 사용했다.
간단한 예제니 보면 바로 이해할 수 있다.

PUT synonyms_test
{
  "settings": {
      "index" : {
          "analysis" : {
              "analyzer" : {
                  "synonym" : {
                      "tokenizer" : "nori_tokenizer",
                      "filter" : ["synonym"]
                  }
              },
              "filter" : {
                  "synonym" : {
                      "type" : "synonym",
                      "synonyms_path" : "analysis/synonyms.txt"
                  }
              }
          }
      }
  },
  "mappings": {
    "_doc": {
      "dynamic": "false",
      "properties": {
        "keyword": {
          "type": "text",
          "analyzer": "synonym",
          "search_analyzer": "synonym",
          "fields": {
            "keyword": {
              "type": "keyword"
            }
          }
        }
      }
    }
  }
}

데이터를 2080과 이공팔공 두개를 삽입했다.

POST synonyms_test/_doc
{
  "keyword":"2080"
}

POST synonyms_test/_doc
{
  "keyword":"이공팔공"
}

그럼 이 두개의 키워드가 동일하게 하나의 명령어로 검색이 되는지 확인해보자.

GET synonyms_test/_search
{
  "query": {
    "match": {
      "keyword": "이공팔공"
    }
  }
}

2080과 이공팔공으로 검색한 결과

댓글()

elasticsearch 7.0 docker 설치 후 변경사항 확인

엘라스틱서치 7.0이 출시했다.

엘라스틱서치 7.0에는 kibana UI변경과 multi mapping type 제거 등의 이슈가 있다.

우선 달라진점을 확인하기 위해 docker에 설치해보자.

설치

elasticsearch

docker run --name elastic7.0 -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:7.0.0

 

kibana

docker run -d --rm --link elastic7.0:elastic-url -e "ELASTICSEARCH_HOSTS=http://elastic-url:9200" -p 5601:5601 --name kibana7.0 docker.elastic.co/kibana/kibana:7.0.0

설치가 끝나고 프로세스를 확인해보면 elastic과 kibana가 올라가 있는 것을 확인할 수있다.

 

kibana UI 확인

키바나에 접속해 보니 엄청 깨끗하다. 몬가 되게 플랫해진 요새 디자인을 하고 있다. 5부터 6까지 변할때도 몬가 키바나가 멋있어졌다고 느꼈는데 이번에 7버전은 더 멋진 것 같다.

그리고 더 대단한 건 요새 대세인 다크모드가 지원된다.

다크모드는 setting > kibana > advanced settings > dark mode 위치에 가면 다음과 같은 설정 하는 부분이 있다.

설정 후 새로고침을 하면 적용되는데 화면이 멋있다.

 

그리고 멀티 맵핑 타입이 제거되고 등등 다른 변경사항이 있는데 아래 링크를 확인하면 된다.

근데 릴리즈하면서 마지막 글에 보면 기존에 elastic을 6버전 이상 사용하고 있으면 굳이 업데이트 할 필요는 없다고 한다 ㅋㅋ

 

변경사항

https://www.elastic.co/blog/elastic-stack-7-0-0-released

댓글()

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등으로 설정해서 진행할수도 있다.




댓글()
  1. Favicon of http://cloud1.tvple.me/movie/ BlogIcon 영화다시보기 2020.08.19 11:59 댓글주소  수정/삭제  댓글쓰기

    잘 보고 갑니다~~

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에서 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

댓글()