728x90
최근에 quadkey를 기반으로 한 poi 조회 API의 응답 속도가 느려져 elasticsearch의 조회 성능을 개선하면서 느낀 몇가지 팁을 공유해볼까 합니다.
timeout
- QueryDsl로 데이터를 조회할 경우
timeout이라는 옵션을 요청에서 보낼 수 있습니다. - timeout을 3초로 설정했을 때, 결과를 받는 시간이 3초가 넘어버리면 해당 결과를 받을 수 없게됩니다.
- 이는 쿼리의 병목현상을 막을 수가 있습니다. Search latency가 느려지는 경우 성능에 영향을 미칠 수 있기 때문입니다.
Search Latency- 일라스틱 서치의 클러스터에 전송된 요청은 큐에 쌓이게 됩니다.
- 이 때, 큐에 요청이 쌓여 지연이 발생하는 것을 Latency라고 부릅니다
- 대기 시간이 길어질 수록 검색 처리 능력은 떨어지게 됩니다
- 혹은 장애가 있는 쿼리가 있을 때, 이후 쿼리의 응답을 받을 수 없게 됩니다.
- 전체 샤드에서 응답이 느린 데이터는 누락될 수 있기 때문에 잘 사용하셔야 합니다.
source
- QueryDsl로 데이터를 조회할 때, 원하는 필드를 응답으로 가져올 수 있습니다.
- 응답하는 필드양이 많을수록 네트워크 사용량이 늘어 속도가 느려지게 됩니다.
- 원하는 필드만
_source에서 지정하여 가져온다면 성능에서 이득을 볼 수 있습니다.
from, size
from은 조회 시작 지점,size는 시작 지점부터의 길이를 나타냄니다- 만약 from이 0이고 size가 10이면 0부터 10까지 값을 가져옵니다
- 다음 페이지의 데이터를 가져오려면 from이 10이고 size를 10으로 둬야 10부터 20까지의 데이터를 가져올 수 있습니다
- 주의할 점은 from이 10이라면 10부터 20까지 데이터를 찾는 것이 아니라, 0부터 20까지 찾은 값 중 10에서 20의 범위를 결과로 가져옵니다
- 그래서 만약에 페이징의 깊이가 깊어진다면 성능에 영향을 끼칠 수 있으니 주의해야 합니다.
must, should
must는 AND연산과 동일합니다.should는 OR연산과 동일합니다.- must의 경우는 아래 조건들과 반드시 일치하는 내용을 가져오므로 범위가 더 좁습니다
- should의 경우는 아래 조건들 중 하나라도 일치하면 데이터를 가져오므로 범위가 더 넓습니다.
- must를 사용하는 경우 좁은 범위를 탐색 가능하므로 빠른 결과를 가져올 수 있습니다
multi search
- 네트워크 IO를 줄이는 가장 좋은 방법은 요청의 개수를 줄이는 것입니다.
- 한번에 많은 요청을 보내는 대신 msearch를 사용하여 여러 인덱스, 혹은 여러 쿼리를 묶어서 한번의 요청으로 결과를 받아 올 수 있습니다.
- 개인적인 경험으로는 여러번의 쿼리를 보내는 것과 msearch로 한번에 요청을 보내는데 응답시간의 차이는 별로 느끼지 못했던 것 같습니다
- 내부에서 병렬적으로 쿼리가 실행되는 것이 아니라 큐와 마찬가지로 동기적으로 처리되는 것 같습니다.
filter
- 일라스틱서치에서는 쿼리와 필터 두가지로 조건을 검색할 수 있습니다
- 필터의 경우는 필터의 결과를 내부적으로 캐싱하게 됩니다.
- 또한 쿼리의 경우는 문장을 분석하는 과정이 추가로 일어나는데 반해, 필터의 경우는 그런 과정이 없으므로 검색이 조금 더 빠릅니다.
728x90
