翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Neptune でステートメントのインデックスを作成する方法
quad のグラフをクエリする場合は、quad の位置ごとに値制約を指定するかどうかを選択できます。このクエリでは、指定した値制約に一致するすべての quad が返ります。
Neptune ではインデックスを使用してグラフクエリパターンを解決します。これらのインデックスは、グラフエッジの 4 つの主要コンポーネントを対象としています。すなわち、サブジェクト (LPG のソース頂点)、述語 (RDF)、プロパティまたはエッジラベル (LPG)、オブジェクト (LPG のターゲット頂点またはプロパティ値)、グラフ (RDF) またはエッジ識別子 (LPG) です。これら 4 つのクワッドコンポーネントの位置には、16 (2^4) のアクセスパターンが存在します。6 つのインデックスを使用して、スキャンやフィルタリングを行うことなく、16 のパターンすべてに対して効率的にクエリを実行できます。各 quad ステートメントインデックスは、異なる順序で連結された 4 つの位置の値で構成されるキーを使用します。16 個のアクセスパスすべてをカバーする quad ステートメントインデックスの可能な組み合わせの 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 つのインデックスに加えて、ラボモードを使用して [OSPG インデックス](features-lab-mode.md#features-lab-mode-features-osgp-index)を有効にすることで、これを大幅に改善できます。
OSPG インデックスの有効化には、次の欠点が伴う場合があります。
+ 挿入速度が最大 23% 遅くなる場合がある。
+ ストレージが最大 20％ 増加する。
+ すべてのインデックスに等しく接する読み取りクエリ (非常にまれです) のレイテンシーが増す場合がある。
ただし、一般的に、多数の個別の述語がある DB クラスターに対しては OSGP インデックスを有効にすることは価値があります。オブジェクトベースの検索 (頂点へのすべての着信エッジの検索や、特定のオブジェクトに接続されたすべてのサブジェクトの検索など) が非常に効率化され、その結果として頂点の削除も効率化されます。
**重要**
OSGP インデックスは、データを読み込む前の空の DB クラスターでのみ有効にできます。
## Neptune データモデルにおける Gremlin ステートメント
Gremlin プロパティグラフデータは、次の 3 つのクラスのステートメントを使用して SPOG モデルで表されます。
+ [頂点ラベルステートメント](gremlin-explain-background-statements.md#gremlin-explain-background-vertex-labels)
+ [エッジステートメント](gremlin-explain-background-statements.md#gremlin-explain-background-edge-statements)
+ [プロパティステートメント](gremlin-explain-background-statements.md#gremlin-explain-background-property-statements)
Gremlin クエリでこれらがどのように使用されるかについては、[Neptune での Gremlin クエリの動作を理解する](gremlin-explain-background.md) を参照してください。