Neptune のグラフデータモデル。 - Amazon Neptune
ディクショナリインデックス作成戦略Gremlin データモデル

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Neptune のグラフデータモデル。

Amazon Neptune グラフデータの基本単位は 4 つの位置 (四角型) の要素で、リソース記述フレームワーク (RDF) の四角形に似ています。Neptune 四角形の 4 つの位置は次のとおりです。

  • subject    (S)

  • predicate  (P)

  • object     (O)

  • graph      (G)

各 quad は、1 つ以上のリソースについてアサーションを実行するステートメントです。ステートメントでは、2 つのリソース間の関係の有無に対してアサーションを行ったり、リソースにプロパティ (キーと値のペア) を付加したりすることができます。通常、四角形の述語値はステートメントの動詞と考えることができます。定義される関係またはプロパティのタイプについて説明します。オブジェクトは、関係のターゲット、またはプロパティの値を表します。次に例を示します。

  • 2 つの頂点間の関係は、ソース頂点識別子を S の位置、ターゲット頂点識別子を O の位置、エッジラベルを P の位置に保存することによって表すことができます。

  • プロパティは、要素識別子を S の位置、プロパティキーを P の位置、プロパティ値を O の位置に保存することで表すことができます。

G グラフの位置は、スタックごとに異なる方法で使用されます。Neptune の RDF データの場合、 G 位置には名前付きグラフ識別子が含まれます。Gremlin のプロパティグラフでは、エッジの場合にエッジ ID 値を保存するために使用されます。それ以外の場合、デフォルトは固定値です。

共有リソース識別子を持つ一連の quad ステートメントではグラフを作成します。

ユーザー向け値のディクショナリ

Neptune は、ほとんどのユーザー向け値を、管理するさまざまなインデックスに直接保存しません。代わりに、それらを個別にディクショナリに保存し、インデックス内の値を 8 バイトの識別子に置き換えます。

  • S、P、または G インデックスに入れられるすべてのユーザー向け値は、このようにしてディクショナリに保存されます。

  • O インデックスでは、数値はインデックスに直接格納されます (インライン化)。これには、date および datetime の値 (エポックからのミリ秒で表される) が含まれます。

  • O インデックスに入れられるその他すべてのユーザー向け値は、ディクショナリに格納され、インデックス内で ID によって表されます。

ディクショナリには、ユーザー向け値から value_to_id インデックス内の 8 バイト ID へのフォワードマッピングが含まれています。

8 バイト ID から値への逆マッピングは、値のサイズに応じて 2 つのインデックスのうちの 1 つに格納されます。

  • id_to_valueインデックスは、内部エンコーディング後に ID を 767 バイト未満のユーザー向け値にマッピングします。

  • id_to_blob インデックスは、ID をより大きいユーザー向け値にマッピングします。

Neptune でステートメントのインデックスを作成する方法

quad のグラフをクエリする場合は、quad の位置ごとに値制約を指定するかどうかを選択できます。このクエリでは、指定した値制約に一致するすべての quad が返ります。

Neptune ではインデックスを使用してクエリを解決します。Andreas Harth 氏と Stefan Decker 氏が 2005 年の論文 (Optimized Index Structures for Querying RDF from the Web) で考察したように、4 つの quad 位置に対して 16 (24) のアクセスパターンがあります。6 つのクアッドステートメントインデックスを使用して、スキャンやフィルタリングを行うことなく、16 のパターンすべてに対して効率的にクエリを実行できます。各 quad ステートメントインデックスは、異なる順序で連結された 4 つの位置の値で構成されるキーを使用します。


       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 がデフォルトで作成しないステートメントインデックスの 1 つは、リバーストラバーサル OSGP インデックスです。このインデックスは、複数のオブジェクトやサブジェクトにまたがって述語を収集できます。代わりに、Neptune はデフォルトで {all P x POGS} の結合スキャンを行うために使用する別のインデックスで、個別の述語を追跡します。Gremlin を使用すると、述語はプロパティまたはエッジラベルに対応します。

グラフ内の個別の述語の数が多くなると、Neptune のデフォルトのアクセス方式は効率が悪くなる場合があります。たとば、Gremlin の場合、エッジラベルが指定されていない in() ステップや、in() を内部で使用するステップ (both() や drop() など) は非常に効率が悪くなる場合があります。

ラボモードを使用した OSGP インデックス作成の有効化

データモデルで個別の述語を多数作成する場合、パフォーマンスが低下し、運用コストが高くなることがありますが、Neptune がデフォルトで維持する 3 つのインデックスに加えて、ラボモードを使用して OSPG インデックスを有効にすることで、これを大幅に改善できます。

注記

この機能は、Neptune エンジンリリース 1.0.1.0.200463.0 からアクセスできます。

OSPG インデックスの有効化には、次の欠点が伴う場合があります。

  • 挿入速度が最大 23% 遅くなる場合がある。

  • ストレージが最大 20％ 増加する。

  • すべてのインデックスに等しく接する読み取りクエリ (非常にまれです) のレイテンシーが増す場合がある。

ただし、一般的に、多数の個別の述語がある DB クラスターに対しては OSGP インデックスを有効にすることは価値があります。オブジェクトベースの検索 (頂点へのすべての着信エッジの検索や、特定のオブジェクトに接続されたすべてのサブジェクトの検索など) が非常に効率化され、その結果として頂点の削除も効率化されます。

重要

OSGP インデックスは、データを読み込む前の空の DB クラスターでのみ有効にできます。

 

Neptune データモデルにおける Gremlin ステートメント

Gremlin プロパティグラフデータは、次の 3 つのクラスのステートメントを使用して SPOG モデルで表されます。

Gremlin クエリでこれらがどのように使用されるかについては、Neptune での Gremlin クエリの動作を理解する を参照してください。