翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # `explain`および`profile`を使用した Gremlin クエリのチューニング Amazon Neptune で Gremlin クエリを調整して、Neptune [explain](gremlin-explain-api.md) および [profile](gremlin-profile-api.md) API から取得したレポートで入手できる情報を使用して、パフォーマンスを向上させることができます。そうすることで、Neptune が Gremlin トラバーサルをどのように処理するのかを理解するのに役立ちます。 **重要** TinkerPop バージョン 3.4.11 に変更が加えられ、クエリの処理方法の正確性が向上しましたが、現時点ではクエリのパフォーマンスに重大な影響を与える場合があります。 たとえば、この種類のクエリの実行速度が大幅に遅くなる可能性があります。 ``` g.V().hasLabel('airport'). order(). by(out().count(),desc). limit(10). out() ``` TinkerPop 3.4.11 の変更により、制限ステップの後の頂点は、最適ではない方法でフェッチされるようになりました。これを回避するには、barrier() ステップを `order().by()` の次の任意のポイントに追加して、クエリを変更できます。例: ``` g.V().hasLabel('airport'). order(). by(out().count(),desc). limit(10). barrier(). out() ``` TinkerPop 3.4.11 が Neptune [エンジンバージョン 1.0.5.0](engine-releases-1.0.5.0.md)で有効になりました。 ## Neptune の Gremlin トラバーサル処理について理解する Gremlin トラバーサルが Neptune に送信されると、トラバーサルをエンジンが実行するための基礎となる実行計画に変換する 主要なプロセスが 3 つあります。パーシング、変換、最適化です。 ![3 つのプロセスが Gremlin クエリを実行プランに変換します。](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/Gremlin_traversal_processing.png) ### トラバーサル解析プロセス トラバーサルを処理する最初のステップは、それを共通言語に解析することです。Neptune では、その共通言語は TinkerPop の一連のステップであり、[TinkerPop API](http://tinkerpop.apache.org/javadocs/3.4.8/full/org/apache/tinkerpop/gremlin/process/traversal/Step.html)の一部です。これらの各ステップは、トラバーサル内の計算単位を表します。 Gremlin トラバーサルを文字列またはバイトコードとしてNeptune に送信できます。REST エンドポイントと Java クライアントドライバ `submit()` メソッドは次の例のように、トラバーサルを文字列として送信します。 ``` client.submit("g.V()") ``` [Gremlin 言語変種 (GLV)](https://tinkerpop.apache.org/docs/current/tutorials/gremlin-language-variants/)を使用するアプリケーションおよび言語ドライバはバイトコードでトラバーサルを送信します。 ### トラバーサル変換プロセス トラバーサルの処理の 2 番目のステップは、その TinkerPop ステップを、変換済みおよび未変換の Neptune ステップセットに変換することです。Apache TinkerPop Gremlin クエリ言語のほとんどのステップは、基盤となる Neptune エンジン上で実行するように最適化された Neptune 固有のステップに変換されます。Neptune に相当する値を含まない TinkerPop ステップがトラバーサルで検出されると、そのステップとその後のすべてのステップは TinkerPop クエリエンジンによって処理されます。 どのような状況でどのようなステップが変換できるかの詳細については、[Gremlin ステップサポート](gremlin-step-support.md)を参照してください。 ### トラバーサル最適化プロセス トラバーサル処理の最後のステップは、オプティマイザを介して変換されたステップと未変換の一連のステップを実行し、最適な実行プランを決定することです。この最適化の出力は、Neptune エンジンが処理する実行計画です。 ## Neptune Gremlin `explain` API を使用してクエリを調整する Neptune explain APIは、Gremlin`explain()` ステップとは同じではありません。これは、クエリの実行時に Neptune エンジンが処理する最終実行プランを返します。処理を実行しないため、使用されるパラメータに関係なく同じプランが返され、実際の実行に関する統計が出力に含まれません。 アンカレッジのすべての空港の頂点を見つける次の単純なトラバーサルを考えます。 ``` g.V().has('code','ANC') ``` このトラバーサルを Neptune `explain` APIで実行するには、2 つの方法があります。最初の方法は、EXPLAIN エンドポイントに対して、次のように REST 呼び出しを行うことです。 ``` curl -X POST https://{{your-neptune-endpoint}}:{{port}}/gremlin/explain -d '{"gremlin":"g.V().has('code','ANC')"}' ``` 2 番目は、`explain` パラメータで Neptune ワークベンチの [%%gremlin](notebooks-magics.md#notebooks-cell-magics-gremlin) セルマジックを使う方法です。これにより、セル本文に含まれるトラバーサルが Neptune `explain`API に渡され、セルを実行すると、結果の出力が表示されます。 ``` %%gremlin explain g.V().has('code','ANC') ``` 結果としての `explain` API 出力は、Neptune のトラバーサルの実行プランを記述します。次の図に示すように、計画には、処理パイプラインに次の 3 つの各ステップが含まれています。 ![単純な Gremlin トラバーサルの API 出力を説明する。](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/Gremlin_explain_output_1.png) ### 変換されないステップを見てトラバーサルを調整する。 Neptune `explain` API 出力で最初に探すものの 1 つは、Neptune ネイティブステップに変換されない Gremlin ステップ用です。クエリプランで、Neptune ネイティブステップに変換できないステップが検出されると、そのステップと計画内の後続のすべてのステップが Gremlin サーバーによって処理されます。 上記の例では、トラバーサル内のすべてのステップが変換されました。このトラバーサルの `explain` API 出力を調べてみましょう。 ``` g.V().has('code','ANC').out().choose(hasLabel('airport'), values('code'), constant('Not an airport')) ``` 下の画像でわかるように、Neptune は `choose()` ステップを変換できませんでした。 ![すべてのステップを変換できるわけではない API 出力を説明する。](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/Gremlin_explain_output_2.png) トラバーサルのパフォーマンスを調整するには、いくつかの方法があります。最初の方法では、変換できなかったステップを排除するような方法で書き直します。もう 1 つの方法では、ステップをトラバーサルの最後に移動して、他のすべてのステップをネイティブステップに変換できるようにします。 変換されないステップを含むクエリプランは、常に調整する必要はありません。変換できないステップがトラバーサルの終わりにあり、グラフのトラバース方法ではなく出力のフォーマットに関連している場合、パフォーマンスにはほとんど影響しません。 ### Neptune `explain` APIからの出力を調べる他の方法で使うのは、インデックスを使用しないステップです。次のトラバーサルは、アンカレッジに着陸するフライトがあるすべての空港を検索します。 ``` g.V().has('code','ANC').in().values('code') ``` このトラバーサルの explain API からの出力は次のとおりです。 ``` ******************************************************* Neptune Gremlin Explain ******************************************************* Query String ============ g.V().has('code','ANC').in().values('code') Original Traversal ================== [GraphStep(vertex,[]), HasStep([code.eq(ANC)]), VertexStep(IN,vertex), PropertiesStep([code],value)] Converted Traversal =================== Neptune steps: [ NeptuneGraphQueryStep(PropertyValue) { JoinGroupNode { PatternNode[(?1, <~label>, ?2, <~>) . project distinct ?1 .] PatternNode[(?1, , "ANC", ?) . project ask .] PatternNode[(?3, ?5, ?1, ?6) . project ?1,?3 . IsEdgeIdFilter(?6) .] PatternNode[(?3, <~label>, ?4, <~>) . project ask .] PatternNode[(?3, ?7, ?8, <~>) . project ?3,?8 . ContainsFilter(?7 in ()) .] }, annotations={path=[Vertex(?1):GraphStep, Vertex(?3):VertexStep, PropertyValue(?8):PropertiesStep], maxVarId=9} }, NeptuneTraverserConverterStep ] Optimized Traversal =================== Neptune steps: [ NeptuneGraphQueryStep(PropertyValue) { JoinGroupNode { PatternNode[(?1, , "ANC", ?) . project ?1 .], {estimatedCardinality=1} PatternNode[(?3, ?5, ?1, ?6) . project ?1,?3 . IsEdgeIdFilter(?6) .], {estimatedCardinality=INFINITY} PatternNode[(?3, ?7=, ?8, <~>) . project ?3,?8 .], {estimatedCardinality=7564} }, annotations={path=[Vertex(?1):GraphStep, Vertex(?3):VertexStep, PropertyValue(?8):PropertiesStep], maxVarId=9} }, NeptuneTraverserConverterStep ] Predicates ========== # of predicates: 26 WARNING: reverse traversal with no edge label(s) - .in() / .both() may impact query performance ``` 出力の下部にある `WARNING` メッセージが発生するのは、トラバーサルの `in()` ステップは、Neptune が維持する 3 つのインデックスのいずれかを使用して処理することができないからです ([Neptune でステートメントのインデックスを作成する方法](feature-overview-storage-indexing.md) および [Neptune の Gremlin ステートメント](gremlin-explain-background-statements.md) を参照)。`in()` ステップにはエッジフィルターが含まれていないため、`SPOG`、`POGS`または`GPSO` インデックスを使って解決できないのです。代わりに、Neptune は要求された頂点を見つけるためにユニオンスキャンを実行しなければならず、これは非常に非効率です。 この状況において、トラバーサルを調整するには、2 つの方法があります。1 つ目は、インデックス付きルックアップを使用してクエリを解決できるように、1 つ以上のフィルタ条件を `in()` ステップに追加します。上記の例で、次のようになります。 ``` g.V().has('code','ANC').in('route').values('code') ``` 修正済みトラバーサルに対する Neptune `explain` API からの出力には、もう `WARNING` メッセージは含まれていません。 ``` ******************************************************* Neptune Gremlin Explain ******************************************************* Query String ============ g.V().has('code','ANC').in('route').values('code') Original Traversal ================== [GraphStep(vertex,[]), HasStep([code.eq(ANC)]), VertexStep(IN,[route],vertex), PropertiesStep([code],value)] Converted Traversal =================== Neptune steps: [ NeptuneGraphQueryStep(PropertyValue) { JoinGroupNode { PatternNode[(?1, <~label>, ?2, <~>) . project distinct ?1 .] PatternNode[(?1, , "ANC", ?) . project ask .] PatternNode[(?3, ?5, ?1, ?6) . project ?1,?3 . IsEdgeIdFilter(?6) . ContainsFilter(?5 in ()) .] PatternNode[(?3, <~label>, ?4, <~>) . project ask .] PatternNode[(?3, ?7, ?8, <~>) . project ?3,?8 . ContainsFilter(?7 in ()) .] }, annotations={path=[Vertex(?1):GraphStep, Vertex(?3):VertexStep, PropertyValue(?8):PropertiesStep], maxVarId=9} }, NeptuneTraverserConverterStep ] Optimized Traversal =================== Neptune steps: [ NeptuneGraphQueryStep(PropertyValue) { JoinGroupNode { PatternNode[(?1, , "ANC", ?) . project ?1 .], {estimatedCardinality=1} PatternNode[(?3, ?5=, ?1, ?6) . project ?1,?3 . IsEdgeIdFilter(?6) .], {estimatedCardinality=32042} PatternNode[(?3, ?7=, ?8, <~>) . project ?3,?8 .], {estimatedCardinality=7564} }, annotations={path=[Vertex(?1):GraphStep, Vertex(?3):VertexStep, PropertyValue(?8):PropertiesStep], maxVarId=9} }, NeptuneTraverserConverterStep ] Predicates ========== # of predicates: 26 ``` この種のトラバーサルを多数実行している場合に取る方法は、有効なオプショナル `OSGP` インデックスを持つ Neptune DB クラスターでそれらを実行することです ([OSGP インデックスの有効化](feature-overview-storage-indexing.md#feature-overview-storage-indexing-osgp) を参照)。`OSGP` インデックスの有効化には欠点があります。 + データをロードする前に、DB クラスターで有効にする必要があります。 + 頂点とエッジの挿入速度が最大 23% 遅くなる場合があります。 + ストレージ使用量は約 20% 増加します。 + すべてのインデックスにリクエストを分散する読み取りクエリでは、レイテンシーが増加する可能性があります。 `OSGP` インデックスがあることは、制限された一連のクエリパターンに対して非常に意味がありますが、それらを頻繁に実行しない限り、3 つのプライマリインデックスを使用して記述するトラバーサルを確実に解決できるようにすることをお勧めします。 ### 多数の述語を使用する Neptune は、グラフ内の各エッジラベルと各個別の頂点またはエッジプロパティ名を述語として扱い、デフォルトで異なる述語の数が比較的少なくなるように設計されています。グラフデータに数千を超える述語が含まれていると、パフォーマンスが低下する可能性があります。 次のような場合は、Neptune `explain` 出力によって警告が表示されます。 ``` Predicates ========== # of predicates: 9549 WARNING: high predicate count (# of distinct property names and edge labels) ``` ラベルとプロパティの数、これにしたがった述語数を減らすためにデータモデルを再加工するのが容易でない場合、トラバーサルを調整する最良の方法は、上で説明したように、有効化した `OSGP` インデックスを持つ DB クラスタ内でこれらを実行することです。 ## Neptune Gremlin `profile` API を使用してトラバーサルを調整する Neptune `profile` API は Gremlin `profile()` ステップとはかなり異なります。`explain` API のように、その出力には、Neptune エンジンがトラバーサルの実行時に使用するクエリプランが含まれます。また、`profile` 出力には、パラメーターの設定方法に基づいて、トラバーサルの実際の実行統計が含まれます。 アンカレッジのすべての空港の頂点を見つける次の単純なトラバーサルを考えます。 ``` g.V().has('code','ANC') ``` `explain` API の場合は、`profile` REST 呼び出しを使用する API を呼び出せます。 ``` curl -X POST https://{{your-neptune-endpoint}}:{{port}}/gremlin/profile -d '{"gremlin":"g.V().has('code','ANC')"}' ``` 2番目は、`profile` パラメータで Neptune ワークベンチの [%%gremlin](notebooks-magics.md#notebooks-cell-magics-gremlin) セルマジックを使う方法です。これにより、セル本文に含まれるトラバーサルが Neptune `profile`API に渡され、セルを実行すると、結果の出力が表示されます。 ``` %%gremlin profile g.V().has('code','ANC') ``` 結果としての `profile` API 出力には、次の図に示すように、Neptune のトラバーサル実行プランとプランの実行に関する統計の両方が含まれます。 ![Neptune profile API 出力の一例。](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/Gremlin_profile_output_1.png) `profile` 出力の場合、実行計画セクションにはトラバーサルの最終実行計画のみが含まれ、中間ステップは含まれません。パイプラインセクションには、実行された物理パイプライン操作と、トラバーサル実行にかかった実際の時間 (ミリ秒単位) が含まれます。ランタイムメトリクスは、2 つの異なるバージョンのトラバーサルの最適化にかかる時間を比較する際に非常に役立ちます。 **注記** トラバーサルの初期ランタイムは、通常、後続のランタイムよりも長くなります。これは、最初のランタイムによって関連するデータがキャッシュされるためです。 `profile` 出力の第 3 セクションには、実行統計とトラバーサルの結果が含まれます。この情報がトラバーサルのチューニングにどのように役立つかを確認するには、次のトラバーサルを検討してください。このトラバーサルでは、名前が「Anchora」で始まるすべての空港と、それらの空港から 2 回のホップで到達可能なすべての空港、戻り空港コード、飛行ルート、および距離が検索されます。 ``` %%gremlin profile g.withSideEffect("Neptune#fts.endpoint", "{your-OpenSearch-endpoint-URL"). V().has("city", "Neptune#fts Anchora~"). repeat(outE('route').inV().simplePath()).times(2). project('Destination', 'Route'). by('code'). by(path().by('code').by('dist')) ``` ### Neptune `profile` API 出力のトラバーサルメトリクス すべての `profile` 出力で使用できる最初のメトリクスセットは、トラバーサルメトリクスです。これらは Gremlin `profile()` ステップメトリクスに似ていますが、いくつかの違いがあります。 ``` Traversal Metrics ================= Step Count Traversers Time (ms) % Dur ------------------------------------------------------------------------------------------------------------- NeptuneGraphQueryStep(Vertex) 3856 3856 91.701 9.09 NeptuneTraverserConverterStep 3856 3856 38.787 3.84 ProjectStep([Destination, Route],[value(code), ... 3856 3856 878.786 87.07 PathStep([value(code), value(dist)]) 3856 3856 601.359 >TOTAL - - 1009.274 - ``` トラバーサルメトリクステーブルの最初の列には、トラバーサルによって実行されるステップがリストされます。最初の 2 つのステップは、一般に Neptune 固有のステップ `NeptuneGraphQueryStep` および `NeptuneTraverserConverterStep` です。 `NeptuneGraphQueryStep` は、Neptune エンジンによってネイティブに変換および実行できるトラバーサルの全体の実行時間を表します。 `NeptuneTraverserConverterStep` は、変換されたステップの出力を TinkerPop トラバーサーに変換するプロセスを表します。TinkerPop トラバーサーを使用すると、ステップを変換できなかったステップを処理したり、結果を TinkerPOP 互換形式で返すことができます。 上記の例では、変換されていないステップがいくつかあるので、これらの各 TinkerPop ステップ (`ProjectStep`、`PathStep`) がテーブルに行として表示されます。 テーブルの 2 列目、`Count`は、ステップを通過した*表現された*トラバーサーの数を報告し、一方で 3 列目、`Traversers`は、[TinkerPop プロファイルステップのドキュメント](https://tinkerpop.apache.org/docs/current/reference/#profile-step)で説明されているように、そのステップを通過したトラバーサーの数を報告します。。 この例では、3,856 個の頂点と 3,856 個のトラバーサーが `NeptuneGraphQueryStep` で返され、これらの数字は残りの処理を通して同じままです。これは `ProjectStep` および `PathStep` 結果をフィルタリングするのではなく、フォーマットしているからです。 **注記** TinkerPop と違って、Neptune エンジンは`NeptuneGraphQueryStep` および `NeptuneTraverserConverterStep` ステップの中で*一括処理*によりパフォーマンスを最適化することはありません。一括処理は、同じ頂点上のトラバーサーを組み合わせて演算オーバーヘッドを削減する TinkerPop オペレーションであり、それが原因で `Count` および `Traversers` の数は異なります。一括処理は、Neptune が TinkerPop に委譲するステップでのみ発生し、Neptune がネイティブに処理するステップでは発生しないため、`Count` および `Traverser` 列はめったに異なりません。 時間]列には、ステップが要したミリ秒数が報告され、`% Dur` 列には、ステップが要した合計処理時間の割合が報告されます。これらは、最も時間がかかったステップを示すことで、チューニング作業を集中させる場所を示すメトリクスです。 ### Neptune `profile` API 出力でのインデックスオペレーションメトリクス Neptune プロファイル API の出力にあるもう 1 つのメトリクスセットは、インデックスオペレーションです。 ``` Index Operations ================ Query execution: # of statement index ops: 23191 # of unique statement index ops: 5960 Duplication ratio: 3.89 # of terms materialized: 0 ``` 次のレポート: + インデックスルックアップの合計数。 + 実行された一意のインデックスルックアップの数。 + 一意のインデックスルックアップに対する総インデックスルックアップの比率。比が低いほど、冗長性が低くなります。 + 用語辞書からマテリアライズされた用語の数。 ### Neptune `profile` API 出力のリピートメトリクス トラバーサルが上記の例のように `repeat()` ステップを実行すると、リピートメトリックを含むセクションが`profile`出力に表示されます。 ``` Repeat Metrics ============== Iteration Visited Output Until Emit Next ------------------------------------------------------ 0 2 0 0 0 2 1 53 0 0 0 53 2 3856 3856 3856 0 0 ------------------------------------------------------ 3911 3856 3856 0 55 ``` 次のレポート: + 行のループカウント (`Iteration`列)。 + ループが訪問した要素の数 (`Visited`列)。 + ループが出力した要素の数 (`Output`列)。 + ループが出力した最後の要素 (`Until`列)。 + ループが発した要素の数 (`Emit`列)。 + ループから後続のループに渡される要素の数 (`Next`列)。 これらのリピートメトリクスは、トラバーサルの分岐係数を理解し、データベースによって処理されている作業量を把握するのに非常に役立ちます。これらの数値を使用して、パフォーマンスの問題を診断できます。特に、同じトラバーサルが異なるパラメータで劇的に異なる場合です。 ### Neptune `profile` API 出力のフルテキスト検索メトリクス トラバーサルが[フルテキスト検索](full-text-search.md)ルックアップを実行すると、上記の例のように、フルテキスト検索 (FTS) メトリクスを含むセクションが `profile` 出力に表示されます。 ``` FTS Metrics ============== SearchNode[(idVar=?1, query=Anchora~, field=city) . project ?1 .], {endpoint=your-OpenSearch-endpoint-URL, incomingSolutionsThreshold=1000, estimatedCardinality=INFINITY, remoteCallTimeSummary=[total=65, avg=32.500000, max=37, min=28], remoteCallTime=65, remoteCalls=2, joinTime=0, indexTime=0, remoteResults=2} 2 result(s) produced from SearchNode above ``` これは、ElasticSearch (ES) クラスターに送信されたクエリを示し、フルテキスト検索に関連するパフォーマンスの問題を特定するのに役立つ ElasticSearch との相互作用に関するいくつかのメトリクスを報告します。 + ElasticSearch インデックスへの呼び出しに関する概要情報: + すべての remoteCalls がクエリを満たすのに必要な合計ミリ秒数 (`total`)。 + remoteCall で費やされた平均ミリ秒数 (`avg`)。 + remoteCall で費やされた最低ミリ秒数 (`min`)。 + remoteCall で費やされた最大ミリ秒数 (`max`)。 + ElasticSearch へのリモートコールによって消費された合計時間 (`remoteCallTime`)。 + ElasticSearch に対して行われたリモートコール数 (`remoteCalls`)。 + ElasticSearch 結果の結合に費やされたミリ秒数 (`joinTime`)。 + インデックスルックアップに費やされたミリ秒数 (`indexTime`)。 + ElasticSearch によって返された結果の総数 (`remoteResults`)。