Neptune でステートメントのインデックスを作成する方法 - Amazon Neptune
OSGP インデックスの有効化Gremlin データモデル

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

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

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

Neptune はインデックスを使用してグラフクエリパターンを解決します。これらのインデックスは、グラフエッジの 4 つの主要コンポーネントにまたがっています。サブジェクト (LPG のソース頂点）、述語 (RDF）、プロパティまたはエッジラベル (LPG）、オブジェクト (LPG のターゲット頂点またはプロパティ値）、グラフ (RDF) またはエッジ識別子 (LPG) です。これら 4 つのクワッドコンポーネントの位置には、16 (2^4) の可能なアクセスパターンがあります。6 つのインデックスを使用してスキャンおよびフィルタリングしなくても、16 パターンすべてを効率的にクエリできます。各 quad ステートメントインデックスは、異なる順序で連結された 4 つの位置の値で構成されるキーを使用します。16 個のアクセスパスすべてをカバーするクワッド統計インデックスの可能な組み合わせの 1 つは次のとおりです。


       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 つのインデックスに加えて、ラボモードを使用して OSGP インデックスを有効にすることで、パフォーマンスが低下し、運用コストが劇的に向上する可能性があります。

注記

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

OSGP インデックスを有効にすると、いくつかの欠点があります。

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

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

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

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

重要

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

 

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

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

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