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

Neptune 그래프 데이터 모델

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

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

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

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

사용자 표시 값 딕셔너리

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

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

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

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

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

Neptune은 쿼리를 해결하기 위해 인덱스를 사용합니다. Andreas Harth와 Stefan Decker는 2005년 논문인 웹 쿼리를 위한 최적화된 인덱스 RDF 구조에서 네 개의 쿼드 위치에 16가지 (2 ⁴) 개의 가능한 액세스 패턴이 있음을 관찰했습니다. 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개만 작성 및 유지합니다.

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

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

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

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

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

데이터 모델이 많은 수의 고유한 조건자를 생성하는 경우 Neptune이 기본적으로 유지 관리하는 세 가지 OSGP인덱스 외에도 Lab Mode를 사용하여 인덱스를 활성화하면 성능이 저하되고 운영 비용이 크게 향상될 수 있습니다.

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

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

 

Neptune 데이터 모델의 Gremlin 문

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

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