

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

# Neptune での Gremlin クエリの処理方法
<a name="gremlin-explain-background-querying"></a>

Amazon Neptune では、より複雑なトラバーサルは、結合を作成するためにパターン間で共有できる名前付き変数の定義に基づいて関係を作成する一連のパターンで表すことができます。以下の例ではこれを示しています。

**質問: 頂点 `v1` の 2 ホップ近傍とは何か?**

```
  Gremlin code:      g.V(‘v1’).out('knows').out('knows').path()
  Pattern:           (?1=<v1>, <knows>, ?2, ?) X Pattern(?2, <knows>, ?3, ?)

  The pattern produces a three-column relation (?1, ?2, ?3) like this:
                     ?1     ?2     ?3
                     ================
                     v1     v2     v3
                     v1     v2     v4
                     v1     v5     v6
```

2 つのパターン (最初のパターンの O 位置と 2 番目のパターンの S 位置) 間で `?2` 変数を共有することで、最初のホップ近傍から 2 番目のホップ近傍への結合を作成します。各 Neptune ソリューションには、3 つの名前付き変数のバインドがあり、これを使用して [TinkerPop Traverser](http://tinkerpop.apache.org/docs/current/reference/#_the_traverser) (パス情報を含む) を再作成できます。

```
```

Gremlin クエリ処理の最初のステップは、クエリを TinkerPop [トラバーサル](http://tinkerpop.apache.org/docs/current/reference/#traversal)オブジェクトに解析することで、これは一連の TinkerPop [ステップ](http://tinkerpop.apache.org/docs/current/reference/#graph-traversal-steps)からなります。オープンソースの [Apache TinkerPop プロジェクト](http://tinkerpop.apache.org/)の一部であるこれらのステップは、リファレンス実装で Gremlin トラバーサルを構成する論理演算子と物理演算子の両方です。どちらも、クエリのモデルを表すために使用されます。これらは、それらが表す演算子のセマンティクスに従ってソリューションを生成できる実行可能な演算子です。たとえば、`.V()` は TinkerPop [GraphStep](http://tinkerpop.apache.org/docs/current/reference/#graph-step) によって表され、実行されます。

これらの既製の TinkerPop ステップは実行可能であるため、このような TinkerPop Traversal は任意の Gremlin クエリを実行して正解を生成できます。ただし、ラージグラフに対して実行すると、TinkerPop ステップは非常に非効率的で低速になることがあります。Neptune はそれらを使用する代わりに、前に説明したように、トラバーサルをパターンのグループで構成される宣言形式に変換しようとします。

Neptune は現在、ネイティブクエリエンジンですべての Gremlin 演算子 (ステップ) をサポートしていません。そのため、可能な限り多くのステップを、変換されたすべてのステップの宣言型論理クエリプランを含む単一の `NeptuneGraphQueryStep` にまとめようとします。理想的には、すべてのステップが変換されます。ただし、変換できないステップが発生した場合、Neptune はネイティブ実行を中断し、すべてのクエリ実行をその時点から TinkerPop ステップに延期します。ネイティブ実行の入出力は行われません。

ステップが論理クエリプランに変換されると、Neptune は一連のクエリオプティマイザを実行し、静的分析と推定基数に基づいてクエリプランを書き換えます。これらのオプティマイザは、範囲カウントに基づく演算子の順序変更、不要または冗長な演算子の除外、フィルタの再配置、異なるグループへの演算子のプッシュなどを行います。

最適化されたクエリプランが作成されると、Neptune はクエリの実行作業を行う物理演算子のパイプラインを作成します。これには、ステートメントインデックスからのデータの読み取り、さまざまなタイプの結合の実行、フィルタリング、順序付けなどが含まれます。パイプラインは、ソリューションストリームを生成し、その後 TinkerPop Traverser オブジェクトのストリームに変換し直します。

## クエリ結果のシリアル化
<a name="gremlin-explain-background-querying-serialization"></a>

Amazon Neptune は現在、TinkerPop レスポンスメッセージシリアライザーを使用して、クエリ結果 (TinkerPop Traversers) をシリアル化されたデータに変換し、ネットワーク経由でクライアントに送信します。これらのシリアル化形式は、かなり冗長になる傾向があります。

たとえば、`g.V().limit(1)` などの頂点クエリの結果をシリアル化するには、 Neptune クエリエンジンが 1 つの検索を実行してクエリ結果を生成する必要があります。ただし、`GraphSON` シリアライザーは、頂点をシリアル化形式にパッケージ化するために、多数の追加の検索を実行します。ラベルを取得するには 1 つの検索、プロパティキーを取得するには 1 つの検索、各キーのすべての値を取得するには、頂点のプロパティキーごとに 1 つの検索を実行する必要があります。

一部のシリアル化形式はより効率的ですが、すべて追加検索が必要です。さらに、TinkerPop シリアライザーは重複検索を回避しないため、多くの検索が不必要に繰り返されることがよくあります。

このため、必要な情報のみを具体的に尋ねるように、クエリを記述することが非常に重要になります。たとえば、`g.V().limit(1).id()` は頂点 ID のみを返し、追加のシリアライザー検索をすべて排除します。[Neptune の Gremlin `profile` API](gremlin-profile-api.md) で、クエリ実行中およびシリアル化中に行われた検索呼び出しの数を確認できます。