Elasticsearch 집합의 성능을 깊이 연구하다

Elasticsearch는 성능을 향상시키기 위해 많은 일을 했지만, 우리는 우리가 무엇을 해서 성능을 향상시킬 수 있는지 알아차리지 못했다.이것은 내가 우리가 사용하고 있는 중합의 성능을 연구할 때 나에게 물어본 것이다.본고에서 나는 Elasticsearch의 캐시에 대해 기본적인 해석을 한 다음에 두 가지 실험을 해서 캐시와 조회가 어떻게 상호작용하는지 검증했다.

Elasticsearch는 어떻게 캐시합니까?

Elasticsearch는 가능한 한 빨리 응답할 수 있도록 모든 캐시가 함께 작동하는 다양한 수준의 캐시를 가지고 있습니다.모든 캐시 수준은 실시간 응답에 가깝다는 약속이 있습니다.이것은 응답 속도가 매우 빠르고 색인에 현재 존재하는 데이터와 일치한다는 것을 의미합니다.

캐시 요청

Elasticsearch에는 자체 스마트 요청 캐시가 있습니다.베이스 인덱스에 대한 업데이트에 따라 이 캐시를 업데이트합니다. 이것은 캐시가 항상 정확하다는 것을 보장합니다.물론 다음과 같은 문제도 있습니다.

Requests where size is greater than 0 will not be cached even if the request cache is enabled in the index settings.

요청 캐시가 작동하지 않을 수 있는 다른 이유는 응답에 포함된 값이 요청마다 바뀌기 때문입니다.예를 들어 응답에 현재 날짜나 무작위로 생성된 숫자가 포함되어 있으면 응답을 캐시할 수 없습니다.
요청 캐시를 조정하는 방법에 대한 자세한 내용은 the documentation 을 참조하십시오.

쿼리 캐시

더 깊은 차원에서 필터 형식 조회 결과는 비트집합이라고 불리는 2진 표시로 캐시할 수 있다.요청 캐시와 마찬가지로 인덱스의 관련 내용이 업데이트되면 캐시가 자동으로 업데이트됩니다.Elasticsearch는 대량의 문서에 대한 질의만 캐시합니다.

Only segments that hold more than 10,000 documents (or 3% of the total documents, whichever is larger) will cache the bitset.

그것은 비교적 작은 단락에 대해 조회를 계산하는 속도가 더 빠를 수 있기 때문에 이 점을 해냈다.Elasticsearch는 캐시가 없는 상황에서 성능을 최적화했기 때문에 캐시를 추가함으로써 속도를 낮추기 쉽다.쿼리 캐시에 대한 추가 정보here를 찾을 수 있습니다.

필드 데이터 캐시

필드 데이터 캐시는 집합과 매우 관련이 있다.파일에 설명된 대로

It loads all the field values to memory in order to provide fast document based access to those values.

필드 데이터 캐시에 충분한 메모리를 보유하지 않으면 집합 속도가 느려집니다.필드 데이터 캐시의 사용 상황을 감시하고 필요에 따라 조정할 수 있습니다.here를 클릭하여 자세한 내용을 확인하십시오.

그것은 흔히 볼 수 있는 검색 요소를 추출하는 데 도움이 됩니까?

검색 캐시는 많은 실제 집합에 매우 유익한 것 같다.색인 필터 서브집합에서 일부 집합을 실행하는 것은 매우 흔하다.이 경우 Elasticsearch에서 필터를 다시 사용할 수 있습니까?아니면 우리가 그것을 도울 수 있을까요?
다음 검색의 성능을 비교해 봅시다.첫 번째 질의는 두 개의 집합에 대해 같은 필터를 지정합니다.

{
  "size": 0,
  "aggregations": {
    "1": {
      "filter": {
        "match": {
          "search_field": "text"
        }
      },
      "aggregations": {
        "items": {
          "top_hits": {
            "size": 100,
            "_source": {
              "includes": "field1"
            }
          }
        }
      }
    },
    "2": {
      "filter": {
        "match": {
          "search_field": "text"
        }
      },
      "aggregations": {
        "items": {
          "top_hits": {
            "size": 100,
            "_source": {
              "includes": "field2"
            }
          }
        }
      }
    }
  }
}

두 번째 검색은 이 필터를 더 높은 단계로 추출합니다. 이것은 집합 공유 결과를 만들어야 합니다.우리는 필터를 통에 싸야 한다.평점이 동일한지 확인하기 위해 필터링:

{
  "query": {
    "bool": {
      "filter": [
        {
          "match": {
            "search_field": "text"
          }
        }
      ]
    }
  },
  "size": 0,
  "aggregations": {
    "1": {
      "top_hits": {
        "size": 100,
        "_source": {
          "includes": "field1"
        }
      }
    },
    "2": {
      "top_hits": {
        "size": 100,
        "_source": {
          "includes": "field2"
        }
      }
    }
  }
}

우리는 이 테스트를 위해 요청 캐시를 비활성화했지만, 검색 캐시와 필드 데이터 캐시는 여전히 그들의 작업을 완성할 수 있습니다.우리는 필터 조회의 단락이 실제로는 만 개의 문서보다 크다는 것을 확보했다.이것은 검색 캐시가 이 때문에 시작되어야 하며, 이 두 검색 사이의 검색 시간에 차이가 없어야 한다는 것을 의미한다.이것이 바로 우리가 본 것이다.

이 두 솔루션 사이에는 성능 차이가 없습니다.쿼리 캐시가 잘 된 것 같습니다.검색 캐시에 대한 요구를 기억하십시오. 두 번째 변체를 더 좋아할 수도 있습니다.현장 데이터가 느려지는 두 가지 상황에서도 마찬가지로 효과가 있다.

집합이 병행 실행됩니까?

일상적인 업무에서, 나는 많은 상황에서 우리가 하나의 조회에 대량의 집합을 두는 것을 보았다.이것은 나로 하여금 집합이 실제로 병행 운행하는 것인지 궁금하게 한다.아니면, 우리는 (예를 들어) 모든 집합에서 하나의 검색을 실행하는 msearch를 통해 응답 시간을 높일 수 있습니까?
이 테스트에서, 우리는 이전과 같은 조회를 실행한다.우리는 한 조회에서 1, 2, 5, 10개의 집합을 테스트했다.우리는 그것을 분할하여 집합할 때와 비교한다. 이렇게 하면 모든 집합이 자신의 조회를 얻을 수 있다.

우리가 모든 집합에 대해 자신의 조회를 제공하고 msearch를 실행할 때, 우리는 성능이 현저히 향상되는 것을 보았다.10회 집합 시 가속 접근 인자 2.이 테스트에서 Elasticsearch 실례는 2개의 사용 가능한 CPU가 있는 docker 용기에서 실행되기 때문에 이 가속은 아마도 당신이 기대하는 가장 좋은 가속입니다.
집합은 기본적으로 병행 운행만 하는 것이 아니라는 것이 분명하다.따라서 응답 시간을 높이려면 집합을 여러 개의 검색으로 분해하는 것이 의미가 있을 수 있습니다.이것은 CPU가 병목이 아닌 경우에만 적용됩니다. 버스트 조회를 통해 총 더 많은 CPU 시간을 사용할 수 있기 때문입니다.

결론

그렇다면 흔히 볼 수 있는 검색 요소를 추출하는 것이 도움이 될까요?일반적으로 말하면, 너는 마땅히 이렇게 해야 한다.Elasticsearch는 이러한 상황을 최적화할 수 있기 때문에 이렇게 할 필요가 없습니다.필터가 검색 캐시에 적합하지 않으면 집합에서 공공 검색 요소를 위로 이동하면 성능이 약간 향상될 수 있습니다.
집합이 병행 실행됩니까?기본적으로 그들은 이렇게 하지 않을 것이다.msearch를 사용하여 그것들을 분할하는 것은 현명할 수 있습니다. 만약 당신이 CPU의 제한을 받지 않는다면.아직 충분히 이용되지 않은 집단에서 이것은 응답 시간을 현저히 높일 수 있다.