1

約 500k のトリプルを含むかなり小さなグラフがあります。また、stats.opt ファイルを生成し、かなり高速なコンピューター (クアッド コア、16 GB RAM、SSD ドライブ) でコードを実行しました。結果セットを反復処理します。結果セットには約 15000 行あり、反復には 4 秒かかります。これはエンドユーザーには受け入れられません。クエリの実行にはわずか 90 ミリ秒しかかかりません (実際の作業はカーソルの反復によって行われるのでしょうか?)。なぜこれが遅いのですか?結果セットの反復を高速化するにはどうすればよいですか?

クエリは次のとおりです。

SELECT  ?apartment ?price ?hasBalcony ?lat ?long ?label ?hasImage ?park ?supermarket ?rooms ?area ?street
WHERE
  { ?apartment dssd:hasBalcony ?hasBalcony .
    ?apartment wgs84:lat ?lat .
    ?apartment wgs84:long ?long .
    ?apartment rdfs:label ?label .
    ?apartment dssd:hasImage ?hasImage .
    ?apartment dssd:hasNearby ?hasNearbyPark .
    ?hasNearbyPark dssd:hasNearbyPark ?park .
    ?apartment dssd:hasNearby ?hasNearbySupermarket .
    ?hasNearbySupermarket dssd:hasNearbySupermarket ?supermarket .
    ?apartment dssd:price ?price .
    ?apartment dssd:rooms ?rooms .
    ?apartment dssd:area ?area .
    ?apartment vcard:hasAddress ?address .
    ?address vcard:streetAddress ?street
    FILTER ( ?hasBalcony = true )
    FILTER ( ?price <= 1000.0e0 )
    FILTER ( ?price >= 650.0e0 )
    FILTER ( ?rooms <= 4.0e0 )
    FILTER ( ?rooms >= 3.0e0 )
    FILTER ( ?area <= 100.0e0 )
    FILTER ( ?area >= 60.0e0 )
  }

(これらの bnode を照会するより良い方法はありますか?hasNearbyPark、?hasNearbySupermarket)

そして、クエリを実行するコード:

dataset.begin(ReadWrite.READ);
Model model = dataset.getNamedModel("http://example.com");
QueryExecution queryExecution = QueryExecutionFactory.create(buildQuery(), model);
ResultSet resultSet = queryExecution.execSelect();
while ( resultSet.hasNext() ) {
    QuerySolution solution = resultSet.next(); ...
4

1 に答える 1

3

ARQ クエリ エンジンについて

まず、ARQ エンジンの仕組みを誤解しているようです。

ResultSet resultSet = queryExecution.execSelect();

上記のすべては、エンジンがクエリをどのように評価するかについてクエリプランを準備することであり、実際にはクエリを評価しないため、ほぼ瞬時に評価されます。

hasNext()あなたの質問に答える実際の作業は、あなたが電話をかけ始めるまで起こりませんnext()。

while ( resultSet.hasNext() ) {
   QuerySolution solution = resultSet.next(); ...

したがって、引用したタイミングが正しくありません。すべての結果を反復処理するのにかかる時間であるため、クエリの評価に 4 秒かかります。

実際の質問について

メソッドが何をするかを示していませんbuildQuery()が、クエリをOp文字列ではなくプログラムで構造として構築していると思いますか? この場合、クエリ エンジンは実際には最適化を適用していない可能性がありますが、私の頭の上ではこれが問題になるとは思いません。op = Algebra.optimize(op);ビルドを返す前に を追加してみることができますがOp、これが大きな違いを生むかどうかはわかりません。

生のクエリが与えられただけで、オプティマイザは適切に機能するように見えます (クエリが結合の並べ替え以外の最適化の範囲を持っているわけではありません)。 .

同様にstats.opt、TDB データセットではなく特定のモデルに対してクエリを実行するため、ファイルが受け入れられるかどうかはわかりません。そのため、クエリ エンジンは TDB エンジンではなく汎用である可能性があります。私は TDB の専門家ではないので、これが事実かどうかはわかりません。

結論

一般に、質問には、セットアップに実際の問題があるかどうか、またはクエリが単純に高価であるかどうかを診断するのに十分な情報がありません。詳細な分析のために、これを最小限のテスト ケース (最小限の完全なコードとサンプル データ) として user@jena.apache.org リストに報告すると便利です。

クエリに関する一般的なコメントとして、多くの範囲フィルターを実行するとコストがかかります。これは、ほとんどの場合に発生する可能性があります。

于 2013-08-29T19:31:20.043 に答える