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

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

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 ステートメント内のユーザー向けの値は通常、辞書インデックスに個別に格納され、ステートメントインデックスは 8 バイトの long 用語識別子を使用してそれらを参照します。これに対する例外として、date および datetime 値 (エポックのミリ秒として表される) などの数値があります。これらは、ステートメントインデックスに直接インラインで格納できます。

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

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 クエリの動作を理解する を参照してください。