0

コンテキスト: 14M トリプル、Blazegraph ワークベンチ。現在、SELECT と ASK を組み合わせたクエリを設計しようとしています。より正確には、仮定が真であるグラフの結果を選択したいと考えています。

私の例では、著者が 1 人、編集者が 1 人の本がたくさんあるとします。彼の本がランダムなパスの長さのプロパティを介してにリンクされている著者からの本を選択したいclient#1。

私の場合、私のデータでは、次のようにクエリを直接実現するには多くの時間がかかります。

SELECT ?id_book
WHERE {?id_book prefix:hasAuthor :author#1.
        ?id_book prefix:linkedToEditor*/prefix:hasClient :client#1}
ORDER by ?id_book

微積分の時間を短縮するために (x 1:1000)、これらのクエリを連続して実現するスクリプトを使用しています。このスクリプトは、著者 n°1 を著者として持つ本を選択します。

SELECT ?id_book
WHERE {?id_book prefix:hasAuthor :author#1}
ORDER by ?id_book

そして、クライアント n°1 にリンクされている場合、1 から n ( id_book#1、id_book#2、 ...、 )の各結果を求めます。id_book#n

ASK {id_book#i prefix:linkedToEditor*/prefix:hasClient :client#1}

ASK クエリが後に続く SELECT クエリは、同じ結果に対する最初の SELECT クエリよりもはるかに高速です。のすべての可能性を探りたいわけではありません?id_book prefix:linkedToEditor*/prefix:hasClient :client#1。リンクが存在する場所に結果を保存したいだけです。FILTER EXISTS または 2 つの SELECT クエリを試しましたが、クエリ時間は同様に長くなります。

SELECT ?id_book
WHERE {?id_book prefix:hasAuthor :author#1.}
FILTER EXIST {?id_book prefix:linkedToEditor*/prefix:hasClient :client#1}
ORDER by ?id_book

また

SELECT ?id_book
WHERE {?id_book prefix:linkedToEditor*/prefix:hasClient :client#1.
    {SELECT ?id_book
        WHERE {?id_book prefix:hasAuthor :author#1.}
    }
}

クエリを 1 つのクエリに最適化するにはどうすればよいですか?

4

1 に答える 1

1

クエリ時間にこのような違いがあるのは少し驚くべきことです。SPARQL エンジンはおそらくクエリを最適化して単純な部分を最初に実行し、その後でより複雑なクエリ プロパティ パスを実行できるはずです。順序付けによって時間が長くなる可能性もありますが、ブール値の結果だけに関心がある場合は、それほど重要ではありません。

いずれにせよ、ネストされたクエリは最初に最も内側で実行されるため、次のようにクエリをネストすることで、「これを最初に実行し、次にそれを実行する」ように強制できます。

select ?id_book {
  #-- first, get the books by author one
  { select ?id_book { ?id_book prefix:hasAuthor :author#1 } }

  #-- then, then check that the book is related to client one
  ?id_book prefix:linkedToEditor*/prefix:hasClient :client#1
}
order by ?id_book
于 2015-08-17T13:06:23.523 に答える