1

数万のドキュメントを含む ML データベースと、それらのドキュメントのすべてまたはサブセットの単純な計算値を返すクエリがあります。ドキュメント数が増加し、「すべてのドキュメント」オプションがタイムアウトせずに確実に実行されなくなり、ドキュメント数が増えるにつれて悪化するだけです。明らかな解決策は、クライアント アプリケーションが他のフォームを使用して結果をページ付けすることです。これはオフラインのバッチ プロセスであるため、全体的な速度は問題ではありません。個々のリクエストを正常に保ちたいだけです。

クエリのページ バージョンは非常に単純です。

declare namespace ns = "http://some.namespace/here"

declare variable $fromCount external;
declare variable $toCount external;

<response> {
  for $doc in fn:doc()/ns:entity[$fromCount to $toCount]
  return
  <doc> omitted for brevity </doc>
} </response>

問題は、要求されたページがドキュメント セットを通過するほどクエリが遅くなることです。おそらく、すべてのドキュメントを順番にロードする必要があるため、正しいタイプであるかどうかを確認し、見つかった$fromCount ns:entitys まで繰り返してから、応答の構築を開始します。

問題の 1 つは、データベースに他の種類のドキュメントがあることです。そのため、単に fn:doc を使用するのは現実的なオプションではありません (ただし、それらは別のディレクトリにあるためxdmp:directory()、オプションになる可能性があります。調べてみます)。

また、現在、ns:entity要素にはインデックスがありません。それは役に立ちますか？これは常にドキュメントのルート ノードであり、ドキュメントは非常に大きいため、インデックスのサイズが気になります。また、(遅い部分) このクエリは要素の値には関心がなく、要素が存在するだけです。

組み込みのページングに API を使用することを考えましsearch:たが、すべてのドキュメントに一致することを目的としたクエリにはやり過ぎのようです。search:search()内部的に構築されるクエリを手動で構築することは確かに可能です。

私が本当に必要としているのは、データベース内の特定のタイプのすべてのルート ノードの効率的なリストです。Marklogicはそのようなことを維持していますか? そうでない場合、インデックスは問題を解決しますか?

編集:xdmp:directory() ML は明らかにすべてのドキュメントのメモリ内リストを高速に格納するため、私の場合の答えはオプションを使用することであることがわかりました。それでも、問題に対するより一般的な解決策がある場合、それは興味深いものになるはずなので、ここで質問を残しておきます.

4

1 に答える 1

2

あなたの分析は正しいです：

おそらく、すべてのドキュメントを順番にロードする必要があるため、正しいタイプであるかどうかを確認し、見つかった $fromCount ns:entitys まで繰り返してから、応答の構築を開始します

通常の答えはcts:search、プラスunfilteredオプションです。そのほうが速いことがわかりましたxdmp:directoryが、スケールが小さくても、ページネーション時間を O(n) として測定できるはずです。http://docs.marklogic.com/guide/performance/unfiltered#chapterを参照してください- 基本的に、データベースは、そうしないように指示しない限り、誤検知を返さないように保護しています。

別のアプローチとしてcts:urisとそのlimitオプションを使用することもできますが、これには、ページ数ではなく開始値の観点からページネーションの状態を管理する必要がある場合があります。たとえば、1 ページ目の最後の項目が「cat」の場合cts:uris、次のページを呼び出すときに「cat」を arg2 として使用します。ページネーションの開始/停止値も引き続き使用できます。それはまだO（n）ですが、はるかに小さいスケールです。

于 2012-10-08T17:37:15.547 に答える