Neptune 그래프 데이터 모델 - Amazon Neptune
딕셔너리인덱싱 전략Gremlin 데이터 모델

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

Neptune 그래프 데이터 모델

Amazon Neptune 그래프 데이터의 기본 단위는 리소스 기술 프레임워크(RDF) 쿼드와 유사한 4위치(쿼드) 요소입니다. Neptune 쿼드의 네 위치는 다음과 같습니다.

  • subject    (S)

  • predicate  (P)

  • object     (O)

  • graph      (G)

각 쿼드는 하나 이상의 리소스에 대한 어설션을 이루는 문입니다. 문은 두 리소스 사이에 관계가 있음을 설명하거나 리소스에 속성(키-값 페어)을 연결할 수 있습니다. 쿼드 조건자 값을 일반적으로 문의 동사로 생각할 수 있습니다. 정의 중인 관계 또는 속성 유형을 설명합니다. 객체는 관계 또는 속성 값의 대상입니다. 예를 들어, 다음과 같습니다.

  • 소스 버텍스 식별자를 S 위치에, 대상 버텍스 식별자를 O 위치에, 엣지 레이블은 P 위치에 저장하여 두 버텍스 간의 관계를 표현할 수 있습니다.

  • 요소 식별자를 S 위치에, 속성 키를 P 위치에, 속성 값을 O 위치에 저장하여 속성을 표현할 수 있습니다.

그래프 위치 G는 스택마다 다르게 사용됩니다. Neptune의 RDF 데이터의 경우, G 위치에 명명된 그래프 식별자가 포함됩니다. Gremlin의 속성 그래프의 경우, 엣지의 엣지 ID 값을 저장하는 데 사용됩니다. 다른 모든 경우에는 기본값이 고정 값입니다.

공유된 리소스 식별자가 있는 쿼드 문 집합이 그래프를 생성합니다.

사용자 표시 값 딕셔너리

Neptune은 대부분의 사용자 표시 값을 유지 관리하는 여러 인덱스에 직접 저장하지 않습니다. 대신 딕셔너리에 별도로 저장하고 인덱스의 값을 8바이트 식별자로 대체합니다.

  • S, P 또는 G 인덱스에 들어갈 수 있는 모든 사용자 표시 값은 이러한 방식으로 딕셔너리에 저장됩니다.

  • O 인덱스에서 숫자 값은 인덱스(인라인)에 직접 저장됩니다. 여기에는 date 및 datetime 값(epoch의 밀리초로 표시)이 포함됩니다.

  • O 인덱스에 포함되는 다른 모든 사용자 표시 값은 딕셔너리에 저장되고 인덱스에는 ID로 표시됩니다.

딕셔너리에는 사용자 표시 값을 value_to_id 인덱스의 8바이트 ID로 순방향 매핑하는 기능이 포함되어 있습니다.

값 크기에 따라 8바이트 ID의 역방향 매핑을 두 인덱스 중 하나의 값에 저장합니다.

  • id_to_value 인덱스는 내부 인코딩 후 767바이트 미만의 사용자 표시 값에 ID를 매핑합니다.

  • id_to_blob 인덱스는 ID를 더 큰 사용자 표시 값에 매핑합니다.

Neptune에서 문을 인덱싱하는 방식

쿼드 그래프를 쿼리하는 경우 각 쿼드 위치에 대하여 값 제한을 지정하거나 지정하지 않을 수 있습니다. 쿼리는 지정한 값 제한에 일치하는 모든 쿼드를 반환합니다.

Neptune은 쿼리를 해결하기 위해 인덱스를 사용합니다. Andreas Harth와 Stefan Decker가 2005년 논문인 웹에서 RDF를 쿼리하기 위한 인덱스 구조 최적화에서 언급했듯이, 4개의 쿼드 위치에서 가능한 액세스 패턴은 16가지(24)입니다. 6개의 쿼드 문 인덱스를 사용하여 스캔하고 필터링하지 않아도 16개의 패턴을 모두 효율적으로 쿼리할 수 있습니다. 각 쿼드 문 인덱스는 서로 다른 순서로 연결된 네 개의 위치 값으로 구성된 키를 사용합니다.


       Access Pattern                                     Index key order
  ----------------------------------------------------    ---------------
   1.  ????  (No constraints; returns every quad)             SPOG
   2.  SPOG  (Every position is constrained)                  SPOG
   3.  SPO?  (S, P, and O are constrained; G is not)          SPOG
   4.  SP??  (S and P are constrained; O and G are not)       SPOG
   5.  S???  (S is constrained; P, O, and G are not)          SPOG
   6.  S??G  (S and G are constrained; P and O are not)       SPOG

   7.  ?POG  (P, O, and G are constrained; S is not)          POGS
   8.  ?PO?  (P and O are constrained; S and G are not)       POGS
   9.  ?P??  (P is constrained; S, O, and G are not)          POGS

  10.  ?P?G  (P and G are constrained; S and O are not)       GPSO
  11.  SP?G  (S, P, and G are constrained; O is not)          GPSO
  12.  ???G  (G is constrained; S, P, and O are not)          GPSO

  13.  S?OG  (S, O, and G are constrained; P is not)          OGSP
  14.  ??OG  (O and G are constrained; S and P are not)       OGSP
  15.  ??O?  (O is constrained; S, P, and G are not)          OGSP

  16.  S?O?  (S and O are constrained; P and G are not)       OSGP

Neptune은 기본적으로 6개의 인덱스 중 3개만 작성 및 유지합니다.

  • SPOG –   Subject + Predicate + Object + Graph로 구성된 키를 사용합니다.

  • POGS –   Predicate + Object + Graph + Subject로 구성된 키를 사용합니다.

  • GPSO –   Graph + Predicate + Subject + Object로 구성된 키를 사용합니다.

이 3개의 인덱스는 가장 일반적인 액세스 패턴 중 많은 부분을 처리합니다. 6개가 아닌 3개의 전체 문 인덱스만 유지하면 스캔 및 필터링 없이 빠른 액세스를 지원하는 데 필요한 리소스가 크게 줄어듭니다. 예를 들어, SPOG 인덱스는 버텍스 또는 버텍스 및 속성 식별자 등 위치의 접두사가 바인딩될 때마다 효율적인 조회를 허용합니다. POGS 인덱스는 P 위치에 저장된 엣지 또는 속성 레이블만 바인딩된 경우 효율적인 액세스를 허용합니다.

문을 찾기 위한 낮은 수준의 API는 일부 위치가 알려지고 나머지 위치는 인덱스 검색을 통해 찾을 수 있도록 남겨지는 문 패턴을 취합니다. Neptune은 문 인덱스 중 하나에 대한 인덱스 키 순서에 따라 알려진 위치를 키 접두사로 작성함으로써 범위 스캔을 수행하여 알려진 위치와 일치하는 모든 문을 검색합니다.

그러나 Neptune이 기본적으로 생성하지 않는 문 인덱스 중 하나는 객체 및 주체로부터 조건자를 수집할 수 있는 역방향 순회 OSGP 인덱스입니다. 대신 기본적으로 Neptune은 {all P x POGS}를 유니온 스캔하는 데 사용하는 별도 인덱스의 명확한 조건자를 추적합니다. Gremlin으로 작업하는 경우 조건자가 속성 또는 엣지 레이블에 해당합니다.

그래프의 명확한 조건자의 수가 커질 경우 Neptune의 기본 액세스 전략이 비효율적으로 될 수 있습니다. 예를 들어 Gremlin에서 엣지 레이블이 주어지지 않은 in() 단계나 both() 또는 drop()과 같이 내부적으로 in()을 사용하는 모든 단계는 비효율적으로 될 수 있습니다.

랩 모드를 사용하여 OSGP 인덱스 생성 활성화

데이터 모델에서 많은 수의 명확한 조건자를 생성하는 경우 성능이 저하되고 운영 비용이 높아질 수 있습니다. 이는 기본적으로 Neptune이 유지 관리하는 3가지 인덱스 외에 OSGP 인덱스를 활성화하기 위한 랩 모드를 사용하여 획기적으로 개선할 수 있습니다.

참고

이 기능은 Neptune 엔진 릴리스 1.0.1.0.200463.0부터 사용할 수 있습니다.

OSGP 인덱스를 활성화하면 몇 가지 단점이 있을 수 있습니다.

  • 삽입 속도가 최대 23% 느려질 수 있습니다.

  • 스토리지가 최대 20% 증가합니다.

  • 매우 드물지만 모든 인덱스를 동일하게 터치하는 읽기 쿼리는 지연 시간이 증가할 수 있습니다.

그러나 일반적으로 많은 수의 명확한 조건자를 사용하여 DB 클러스터에 대한 OSGP 인덱스를 활성화하는 것이 좋습니다. 객체 기반 검색은 매우 효율적이므로(예를 들어 버텍스로 들어오는 모든 엣지 또는 지정된 객체에 연결된 모든 주체를 찾는 경우), 결과적으로 버텍스를 삭제하는 것이 훨씬 더 효율적입니다.

중요

OSGP 인덱스는 날짜를 로드하기 전에 빈 DB 클러스터에서만 활성화할 수 있습니다.

 

Neptune 데이터 모델의 Gremlin 문

Gremlin 속성 그래프 데이터는 다음과 같은 3가지 문 클래스를 사용하여 SPOG 모델에서 표현됩니다.

Gremlin 쿼리에서 이를 사용하는 방법에 대한 설명은 Neptune에서 Gremlin 쿼리가 작동하는 방법 이해를 참조하세요.