Neptune における SPARQL クエリエンジンの仕組み - Amazon Neptune

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

Neptune における SPARQL クエリエンジンの仕組み

SPARQL explain 機能が提供する情報を使用するには、Amazon Neptune SPARQL クエリエンジンの仕組みについてのいくつかの詳細を理解する必要があります。

エンジンはすべての SPARQL クエリを演算子のパイプラインに変換します。最初の演算子から始まり、バインドリストとして知られる中間ソリューションはこの演算子パイプラインを介して進みます。バインドリストは、テーブルヘッダーがクエリ内で使用される変数のサブセットであるテーブルとして考えることができます。テーブルの各行は、評価ポイントまでの結果を表します。

使用するデータには 2 つの名前空間プレフィックスが定義されていると仮定します。

@prefix ex: <http://example.com> . @prefix foaf: <http://xmlns.com/foaf/0.1/> .

以下に示しているのは、このコンテキストのシンプルなバインドの例です。

?person | ?firstName ------------------------------------------------------ ex:JaneDoe | "Jane" ex:JohnDoe | "John" ex:RichardRoe | "Richard"

3 人ごとに、このリストは ?person 変数をこの人物の識別子にバインドし、?firstName 変数をこの人物の名前にバインドします。

一般的なケースでは、たとえばデータに値がないクエリに変数の OPTIONAL 選択がある場合には、変数はバインドしないままにできます。

PipelineJoin 演算子は、explain 出力にある Neptune クエリエンジン演算子の例です。ここでは、前の演算子からの一連の着信バインドを入力として使用し、これを 3 つのパターン (つまり、(?person, foaf:lastName, ?lastName)) に結合します。この演算では、入力ストリームに ?person 変数のバインドを使用し、これを 3 つのパターンに置き換えて、データベースから 3 つを検索します。

前のテーブルからの着信バインドのコンテキストで実行するとき、PipelineJoin は次に示す 3 つの検索を評価します。

(ex:JaneDoe, foaf:lastName, ?lastName) (ex:JohnDoe, foaf:lastName, ?lastName) (ex:RichardRoe, foaf:lastName, ?lastName)

このアプローチはアズバウンド評価と呼ばれます。この評価プロセスのソリューションは、検出された ?lastName を着信ソリューションに当てはめて、着信ソリューションに再び結合されます。3 人の人物のすべての姓が見つかったとすると、演算子は次のような送信バインドリストを生成します。

?person | ?firstName | ?lastName --------------------------------------- ex:JaneDoe | "Jane" | "Doe" ex:JohnDoe | "John" | "Doe" ex:RichardRoe | "Richard" | "Roe"

次に、この送信バインドリストは、パイプラインの次の入力として機能します。最終的に、パイプラインの最後の演算子の出力はクエリの結果を定義します。

演算子パイプラインは多くの場合に直線的です。つまり、各演算子は単一に接続された演算子のソリューションを発行します。ただし、一部の場合、よる複雑な構造になることができます。たとえば、SPARQL クエリの UNION 演算子は Copy 演算にマッピングされます。この演算はバインドを複製し、このコピーを 2 つのサブプラン (1 つは UNION の左側、もう 1 つは右側) に転送します。

演算子についての詳細は、「Neptune SPARQL explain 演算子」を参照してください。