2

MarkLogic の異なるグラフ (コレクション) にある類似のトリプルを分離する必要があります。これを機能させるには、トリプルを取得するグラフを指定する必要があります。私のアプローチは次のとおりです。

cts:triples(
  (),
  sem:iri("http://something/predicate#somepredicate"), "SomeObject", (), (),
  cts:collection-query("someCollection") )  

これは機能しますが、コレクション クエリが原因でパフォーマンスが低下します。結果を特定のグラフのこれらのみに制限するより良い方法はありますか?

4

2 に答える 2

3

ラップトップで 7.0-4 を使用して、このテスト ケースを作成しようとしました。私にはかなり速いように思えます: 見て、あなたがしていることとどこが違うかを見てください. あなたのクエリは多くのトリプルを返し、それがボトルネックになっていると思います。トリプルのマッチングは非常に高速ですが、多数のトリプルを返すのは比較的遅くなる可能性があります。

まず、タスクボットを使用していくつかのトリプルを生成しましょう。

(: insert test documents with taskbot :)
import module namespace tb="ns://blakeley.com/taskbot"
  at "src/taskbot.xqm" ;
import module namespace sem="http://marklogic.com/semantics" 
  at "MarkLogic/semantics.xqy";

tb:list-segment-process(
  (: Total size of the job. :)
  1 to 1000 * 1000,
  (: Size of each segment of work. :)
  500,
  (: Label. :)
  "test/triples",
  (: This anonymous function will be called for each segment. :)
  function($list as item()+, $opts as map:map?) {
    (: Any chainsaw should have a safety. Check it here. :)
    tb:maybe-fatal(),
    let $triples := $list ! sem:triple(
      sem:iri("subject"||xdmp:random()),
      sem:iri("predicate"||xdmp:random(19)),
      "object"||xdmp:random(49),
      sem:iri('graph'||xdmp:random(9)))
    return sem:rdf-insert($triples)
    ,
    (: This is an update, so be sure to commit each segment. :)
    xdmp:commit() },
  (: options - not used in this example. :)
  map:new(map:entry('testing', '123...')),
  (: This is an update, so be sure to say so. :)
  $tb:OPTIONS-UPDATE)

現在、タスクボットはタスク サーバー上でほとんどの作業を行っています。したがって、監視するErrorLog.txtか、CPU がダウンしてトリプル カウントが 1M に達するのを待ちます。その後、ロードしたものを見てみましょう。

count(cts:triples()),
count(cts:triples((), sem:iri("predicate0"))),
count(cts:triples((), (), "object0")),
count(
  cts:triples((), (), (), (), (), cts:collection-query("graph0")))
=>
1000000
49977
19809
100263

述語、オブジェクト、およびコレクションに対して異なるカウントが得られる場合があります。データがランダムに生成されたことを思い出してください。しかし、クエリを試してみましょう。

count(
  cts:triples(
    (), sem:iri("predicate0"), "object0",
    (), (), cts:collection-query("graph0")))
, xdmp:elapsed-time()

結果:

100
PT0.004991S

それは私にはかなり速いようです:5ミリ秒。データがランダムに生成されたため、異なるカウントが得られる場合がありますが、近いはずです。

ここで、結果セットが大きくなると、これが遅くなります。例えば:

count(
  cts:triples(
    (), (), (),
    (), (), cts:collection-query("graph0")))
, xdmp:elapsed-time()
=>
100263
PT0.371252S

count(cts:triples())
, xdmp:elapsed-time()
=>
1000000
PT2.906235S

count(cts:triples()[1 to 1000])
, xdmp:elapsed-time()
=>
1000
PT0.002707S

ご覧のとおり、応答時間は、トリプルの数でおおよそ O(n) です。実際には O(n) よりも少し優れていますが、その範囲内です。いずれにせよcts:collection-query、問題のようには見えません。

于 2014-12-10T18:35:05.020 に答える
0

コレクションクエリがパフォーマンスの悪い部分になるとしたら、私は驚くでしょう。多くの結果が返されるだけで、処理が遅く見える可能性があることに惑わされないでください。count または xdmp:estimate に入れて除外します。

cts:triples とは別に、FROM または GRAPH ステートメントを使用した sem:sparql しか考えられません。

チッ!

于 2014-12-10T14:24:48.953 に答える