원래 2018년 5월 29일 ObjectRocket.com/blog에 게시되었습니다.
Rackspace Technology가 자주 받는 Elasticsearch® 지원 요청 중 하나는 "제 응답 시간을 도와주시겠습니까?"입니다. 또는 "내 쿼리에 시간이 오래 걸립니다. 어떻게 해야 하나요?"
두 가지 접근 방식
이러한 유형의 질문을 받을 때마다 다음 두 가지 주요 영역을 살펴보는 것으로 시작합니다.
- 운영측 – 현재 시스템 리소스와 기본 Elasticsearch 옵션을 살펴보세요.
- 개발측 - 쿼리, 쿼리 구조, 찾고 있는 데이터 매핑을 살펴보세요.
Elasticsearch 최적화에 대한 일련의 블로그 게시물 중 이 첫 번째 부분에서는 이 두 영역 중 후자에 초점을 맞춥니다. 느린 쿼리를 얻고, DSL(Domain Specific Language) 쿼리 언어에 대해 논의하고, Elasticsearch 쿼리를 개선하는 데 도움이 될 수 있는 옵션을 살펴봅니다.
질의 속도가 얼마나 느립니까?
첫 번째 단계는 클러스터에 쿼리를 보내는 데 걸리는 시간을 확인하는 것입니다. Elasticsearch 문서에는 느린 로그를 설정하는 방법이 명확하지 않으므로 이 게시물에서 몇 가지 예를 보여드리겠습니다.
첫째, Elasticsearch에는 느린 로그의 색인 생성과 느린 로그 검색의 두 가지 버전이 있습니다. 우리가 해결하려는 문제는 느린 쿼리와 관련이 있기 때문에 느린 로그 검색에 중점을 둡니다. 그러나 이것이 문서를 인덱싱하거나 추가하는 동안 성능 문제에 관한 것이라면 인덱스 느린 로그를 살펴보겠습니다.
Elasticsearch의 모든 버전은 기본적으로 느린 로그를 해제하므로 클러스터 설정과 인덱스 설정을 모두 몇 가지 업데이트해야 합니다. 다음 예제에서는 Elasticsearch 6.2를 다루지만 여기에서 이전 버전에 대한 정보를 찾을 수 있습니다. $ES_version을 다음으로 바꾸십시오. 작업 중인 버전(예:버전 5.5)
-
PUT 보내기 _cluster에 요청 켜고 싶은 느린 로그의 수준을 정의하는 API:경고, 정보, 디버그 및 추적.(로깅 수준에 대한 추가 정보)
curl -XPUT https://localhost:$ES_PORT/_cluster/settings -H '콘텐츠 유형:애플리케이션/json' -d'
{
"일시적인" :{"logger.index.search.slowlog" :"DEBUG", "logger.index.indexing.slowlog" :"DEBUG"}}'
Elasticsearch는 인덱스 수준에서 모든 느린 로깅을 활성화하므로 인덱스 _settings에 요청을 보낼 수 있습니다. 켜는 API입니다. 월별, 분기별 등으로 색인을 순환하는 경우에도 색인 템플릿에 추가해야 합니다.
-
도달하려는 느린 로그 시간 임계값과 일치하도록 인덱스 설정에 대한 API 호출을 조정합니다. 값을 0으로 설정하여 인스턴스를 프로파일링하고 전송된 모든 쿼리를 수집하거나 -1로 설정하여 느린 로그를 끌 수 있습니다.
-
_clustersettings에서 사용한 것과 동일한 로그 수준 설정을 사용합니다. 이 예에서는
DEBUG
.ES_PORT
지속적인 환경 변수입니다.curl -XPUT https://localhost:$ES_PORT/*/_settings?pretty -H '콘텐츠 유형:application/json' -d '{"index.search.slowlog.threshold.query.debug":"-1" ,"index.search.slowlog. threshold.fetch.debug":"-1",}'
이제 로그를 수집해야 합니다. 느린 로그는 샤드별로 생성되고 데이터 노드별로 수집됩니다. 5개의 기본 샤드(기본값)를 보유하는 데이터 노드가 하나뿐인 경우 느린 로그에 쿼리 하나에 대해 5개의 항목이 표시됩니다. Elasticsearch의 검색은 각 샤드 내에서 발생하므로 각 샤드에 대해 하나씩 표시됩니다. 느린 로그는 다음 기본 위치에 데이터 노드별로 저장됩니다. /var/log/elasticsearch/$ClusterID_index_slowlog_query 및 /var/log/elasticsearch/$ClusterID_index_slowlog_fetch .보시다시피 검색 속도가 느린 로그는 검색 단계인 가져오기 및 쿼리에 따라 별도의 로그 파일로 다시 나뉩니다.
이제 로그에 결과가 있으므로 항목을 가져와서 분리할 수 있습니다.
[2018-05-21T12:35:53,352][DEBUG ][index.search.slowlog.query] [DwOfjJF] [blogpost-slowlogs][4] took[1s], took_millis[0], types[], stats[], search_type[QUERY_THEN_FETCH], total_shards[5], source[{"query":{"match":{"name": {"query":"hello world", "operator":"OR","prefix_length":0,"max_expansions":50,"fuzzy_transpositions" :true, "lenient":false,"zero_terms_query": "NONE","boost":1.0}}},"sort":[{"price": {"order":"desc"}}]}],
여기에 다음이 표시됩니다.
- 날짜 타임스탬프
- 로그 수준
- 슬로우로그 유형
- 노드 이름
- 색인
- 샤드 번호
- 시간 소요
- 쿼리 본문(_source>)
너무 오래 걸리는 것으로 확인된 쿼리를 얻은 후 다음 도구를 사용하여 분석할 수 있습니다.
_프로필 API
_프로필 API는 검색에 대한 정보 페이지를 제공하고 각 샤드에서 발생한 일을 각 검색 구성 요소의 개별 타이밍까지 세분화합니다. 검색이 상세할수록 _profile 출력이 더 상세해집니다.
Kibana 프로파일링 도구
Kibana® 도구는 _profile과 함께 사용됩니다. API. 개별 검색 구성 요소와 완료하는 데 걸리는 시간에 대한 멋진 시각적 폭포수 표현을 제공합니다. 다시 말하지만, 이를 통해 쿼리의 문제 영역을 선택할 수 있습니다.
Elasticsearch의 두 단계:쿼리 후 가져오기
이제 느린 쿼리를 식별하고 프로파일러를 통해 실행했습니다. 개별 구성 요소 시간 결과를 보면 검색 속도가 빨라지지는 않았습니다. 이제 뭐? 쿼리 작동 방식을 이해하고 다음 두 단계를 거치면 속도와 관련성 모두에서 Elasticsearch에서 최상의 결과를 얻을 수 있는 방식으로 쿼리를 재설계할 수 있습니다.
쿼리 단계
- 조정자 노드가 쿼리를 수락합니다.
- 조정자는 검색 중인 색인을 식별합니다.
- 조정자는 인덱스에 대한 샤드를 포함하는 노드 목록을 생성합니다(기본 및 복제본 혼합).
- 조정자가 노드에 쿼리를 보냅니다.
- 노드의 샤드가 쿼리를 처리합니다.
- 쿼리는 기본적으로 상위 10개 문서에 대해 점수가 매겨집니다.
- 목록이 조정자 노드로 다시 전송됩니다.
가져오기 단계
- 가져오기 단계는 코디네이터 노드에서 시작하여 각 샤드에서 보낸 50개(5개 샤드 x 10개) 결과 중 상위 10개 문서를 결정합니다.
- 조정자는 상위 10개 문서에 대한 요청을 샤드에 보냅니다.(이것은 최고 점수 문서를 포함하는 하나의 샤드이거나 여러 샤드에 흩어져 있을 수 있습니다.)
목록이 반환된 후 마스터는 쿼리 응답의 _hits 섹션에 문서를 표시합니다.
결과 점수
결과 점수는 Elasticsearch의 핵심입니다. 일반적으로 검색 엔진을 사용할 때 가장 정확한 결과를 원합니다. 예를 들어, 과일인 키위를 검색하는 경우 결과에 키위 구두약이 포함되지 않기를 바랍니다. ,빠른 검색이 있지만 결과가 원하는 것이 아닌 경우 전체 검색이 시간 낭비이기 때문에 여기에서 언급하는 것이 중요합니다. 그렇다면 검색 속도를 높이는 방법은 무엇입니까?
필터
검색 성능을 향상시키는 한 가지 방법은 필터를 사용하는 것입니다. 필터링된 쿼리는 가장 친한 친구가 될 수 있습니다. 검색의 필터는 문서 점수의 결과에 영향을 미치지 않으므로 검색 필드를 줄이는 데 리소스를 거의 사용하지 않으므로 먼저 필터링하는 것이 중요합니다.
필터링된 쿼리를 사용하여 부울 일치로 작업하면 Y가 포함되어 있는지 여부에 대한 점수를 매기기 전에 X가 포함된 모든 문서를 검색할 수 있습니다. 또한 필터를 캐시할 수 있습니다.
필터가 Elasticsearch 쿼리의 속도를 높이는 유일한 방법은 아닙니다. 쿼리 성능을 개선하는 데 사용할 수 있는 더 많은 방법을 향후 블로그에서 다룰 것입니다.
요약
몇 가지 간단한 단계로 쿼리를 최적화할 수 있습니다.
- 장기 실행 쿼리를 식별할 수 있도록 느린 로깅 사용
- _프로파일링 API를 통해 식별된 검색을 실행하여 개별 구성요소의 타이밍 확인
- 필터링, 필터링, 필터링
Elasticsearch 관리에 대해 질문이 있습니까? 무료 평가판을 포함하여 모든 인스턴스에 대한 깊은 Elasticsearch 전문 지식을 갖춘 데이터베이스 관리자에 대한 액세스가 포함됩니다. 개발에 집중하고 Elasticsearch 관리를 처리해 드리겠습니다.
Kibana와 함께 Elasticsearch 6의 무료 평가판을 사용해 보고 싶습니까? 시작하고 질문이 있으면 알려주세요.
피드백 탭을 사용하여 의견을 작성하거나 질문하십시오. 영업 채팅을 클릭할 수도 있습니다. 지금 채팅하고 대화를 시작하세요.