읽기 쿼리를 가속화할 수 있는 Neptune 조회 캐시 - Amazon Neptune

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

읽기 쿼리를 가속화할 수 있는 Neptune 조회 캐시

Amazon Neptune은 인스턴스 NVMe SSD 기반을 사용하여 속성 값 또는 R5d 리터럴을 자주 반복적으로 조회하는 쿼리의 읽기 성능을 향상시키는 조회 캐시를 구현합니다. RDF 조회 캐시는 이러한 값을 빠르게 액세스할 수 있는 볼륨에 임시로 저장합니다. NVMe SSD

이 기능은 Amazon Neptune 엔진 버전 1.0.4.2.R2(2021년 6월 1일)부터 사용할 수 있습니다.

메모리가 아닌 클러스터 스토리지 볼륨에서 속성 값이나 리터럴을 검색해야 하는 경우 많은 수의 RDF 꼭짓점과 간선 또는 여러 개의 트리플의 속성을 반환하는 읽기 쿼리의 경우 지연 시간이 길어질 수 있습니다. 자격 증명 그래프에서 많은 수의 전체 이름을 반환하거나 사기 감지 그래프에서 IP 주소를 반환하는 장기 실행 읽기 쿼리를 예로 들 수 있습니다. 쿼리에서 반환되는 속성값 또는 RDF 리터럴 수가 증가하면 사용 가능한 메모리가 줄어들어 쿼리 실행 성능이 크게 저하될 수 있습니다.

Neptune 조회 캐시의 사용 사례

조회 캐시는 읽기 쿼리가 매우 많은 수의 꼭짓점과 간선 또는 세 개의 속성을 반환하는 경우에만 유용합니다. RDF

쿼리 성능을 최적화하기 위해 Amazon Neptune은 R5d 인스턴스 유형을 사용하여 이러한 속성값 또는 리터럴에 대한 대량 캐시를 생성합니다. 그러면 캐시에서 검색하는 것이 클러스터 스토리지 볼륨에서 검색하는 것보다 훨씬 빠릅니다.

일반적으로 다음 세 조건이 모두 충족되는 경우에만 조회 캐시를 활성화하는 것이 좋습니다.

  • 읽기 쿼리의 지연 시간이 증가하는 경우.

  • 또한 읽기 쿼리를 실행할 때 BufferCacheHitRatio CloudWatch 지표가 감소하는 것을 관찰할 수 있습니다 (참조). 아마존을 이용한 Neptune 모니터링 CloudWatch

  • 읽기 쿼리가 결과를 렌더링하기 전에 반환 값을 구체화하는 데 많은 시간을 소비하고 있는 경우(쿼리에 대해 구체화되고 있는 속성값의 수를 확인하는 방법은 아래 Gremlin 프로필 예제 참조).

참고

이 기능은 위에서 설명한 특정 시나리오에서만 유용합니다. 예를 들어, 조회 캐시는 집계 쿼리에 전혀 도움이 되지 않습니다. 조회 캐시를 활용할 수 있는 쿼리를 실행하는 경우가 아니라면 동일하고 비용이 저렴한 R5 인스턴스 유형 대신 R5d 인스턴스 유형을 사용할 이유가 없습니다.

Gremlin을 사용하는 경우 그렘린 profile API로 쿼리의 구체화 비용을 평가할 수 있습니다. '인덱스 작업'에는 실행 중에 구체화된 용어 수가 표시됩니다.

Index Operations Query execution: # of statement index ops: 3 # of unique statement index ops: 3 Duplication ratio: 1.0 # of terms materialized: 5273 Serialization: # of statement index ops: 200 # of unique statement index ops: 140 Duplication ratio: 1.43 # of terms materialized: 32693

구체화된 숫자가 아닌 용어의 수는 Neptune이 수행해야 하는 용어 조회 횟수에 정비례합니다.

조회 캐시 사용

조회 캐시는 기본적으로 자동 활성화되는 R5d 인스턴스 유형에서만 사용할 수 있습니다. R5dNeptune 인스턴스는 인스턴스와 R5 동일한 사양에 최대 1.8TB의 NVMe 로컬 기반 스토리지를 제공합니다. SSD 조회 캐시는 인스턴스별로 다르며, 혜택을 받는 워크로드는 특히 Neptune 클러스터의 R5d 인스턴스로 전달되고 다른 워크로드는 R5 또는 다른 인스턴스 유형으로 전달될 수 있습니다.

Neptune 인스턴스에서 조회 캐시를 사용하려면 해당 인스턴스를 R5d 인스턴스 유형으로 업그레이드하면 됩니다. 이렇게 하면 Neptune은 자동으로 DB 클러스터 파라미터를 (활성화) 1 로 설정하고 neptune_lookup_cache 해당 특정 인스턴스에 조회 캐시를 생성합니다. 그런 다음 를 사용하여 캐시가 인스턴스 상태 API 활성화되었는지 확인할 수 있습니다.

마찬가지로 특정 인스턴스에서 조회 캐시를 비활성화하려면 인스턴스 규모를 R5d 인스턴스 유형에서 동등한 R5 인스턴스 유형으로 축소하세요.

R5d 인스턴스가 시작되면 조회 캐시가 활성화되고 콜드 스타트 모드가 됩니다. 즉, 비어 있습니다. Neptune은 쿼리를 처리하는 동안 먼저 조회 캐시에서 속성 RDF 값이나 리터럴을 확인하고 아직 없는 경우 추가합니다. 이렇게 하면 캐시가 점차 워밍업됩니다.

속성-값 또는 RDF -리터럴 조회가 필요한 읽기 쿼리를 R5d 리더 인스턴스로 보내면 캐시가 워밍업되는 동안 읽기 성능이 약간 저하됩니다. 그러나 캐시를 워밍업하면 읽기 성능이 크게 향상되고 클러스터 스토리지가 아닌 캐시에 조회가 발생하여 I/O 비용이 감소할 수도 있습니다. 메모리 사용률도 향상됩니다.

라이터 인스턴스가 R5d인 경우 쓰기 작업마다 조회 캐시를 자동으로 워밍업합니다. 이 접근 방식은 쓰기 쿼리의 지연 시간을 약간 늘리지만, 조회 캐시를 더 효율적으로 워밍업합니다. 그런 다음 property-value 또는 RDF -literal 조회가 필요한 읽기 쿼리를 작성기 인스턴스로 보내면 값이 이미 캐시되어 있기 때문에 읽기 성능이 즉시 향상되기 시작합니다.

또한 R5d 라이터 인스턴스에서 대량 로더를 실행하는 경우 캐시 때문에 성능이 약간 저하될 수도 있습니다.

조회 캐시는 각 노드별로 적용되므로, 호스트 교체는 캐시를 콜드 스타트로 재설정합니다.

DB 클러스터 파라미터를 (비활성화) 로 설정하여 DB 클러스터의 모든 인스턴스에서 조회 캐시를 일시적으로 비활성화할 수 있습니다. neptune_lookup_cache 0 하지만 일반적으로 특정 인스턴스 규모를 R5d 인스턴스 유형에서 R5 인스턴스 유형으로 축소하여 해당 인스턴스의 캐시를 비활성화하는 것이 더 합리적입니다.