検索としてスニペットを使用すると便利ですか？

Question

私は自分のアプリで先行入力を実装しようとしています。検索では、ドキュメントで推奨されているように、要素範囲のインデックスで作業することを提案しています。問題は、私のユースケースに合わないことです。

検索文字列が検索されるコンテンツの先頭にない限り、これを使用した人は誰でも知っているので、結果は返されません。先頭と末尾のワイルドカードを使用しないと、これで必要なものが返されません。

単語に基づいて検索するだけでなく、結果のスニペット（サーバー側のコードで切り捨てられたもの）を自分の先行入力の候補として返すのではなく、私は考えていました。

私はパフォーマンスを比較する良い方法がないので、これが実用的かどうか、またはそれが遅すぎるかどうかについてのいくつかの洞察を期待していました。

また、答えに出てくる可能性があるので、「チャンク要素範囲インデックス」についての記事を読んでいますが、MarkLogicを初めて使用しているため、頭や尾を作ることはできません。私のアプリにそれを適応させることができます。

Answer 1

私はChunked Element Range Indexesのブログ記事を書いて、私のパフォーマンス番号が私のインデックスの驚くほど大きな文書によって歪曲していることを知りました。その大きな文書を削除すると、ワイルドカードマッチングのような他のテクニックの多くが突然ずっと高速になりました。私が使用した他のすべての検索エンジンでは、ワイルドカード検索を導入しようとすると、早急に、先行シナリオでのパフォーマンスと柔軟性が向上しないため、驚いていました。私は自分の投稿を一般公開にしないことにしましたが、誤って他の人が私のためにそれをしたので、まだ有効なオプションがあるので、そこに残すことにしました。

MarkLogicには複数のワイルドカードインデックスが用意されているため、実際にはその領域で多くのことができます。しかし、検索スニペットは、私は彼らがいくつかのオーバーヘッドを追加すると信じて、それを行うための正しい方法ではありません。 cts：searchまたは他のCTS呼び出しの1つに、レキシコンと一致するように呼び出します。私はcts：element-value-matchがほしいと思っています。これはワイルドカードが範囲索引と一致するため、すべてがメモリに格納されているため、高速になります。可能であれば、db上のすべてのワイルドカードインデックスを有効にしてください。

MarkLogic HTTPサーバーのカスタムXQueryスクリプトから呼び出す必要があります。私は通常のようにREST拡張を推奨していません。ほとんどの先行シナリオを正しく実行するにはできるだけストリームリニアにする必要があるためです（つまり、十分速い）。

レンジインデックスの値のセットを100,000未満に減らす方法を見つけることをお勧めします。これは、マッチすることが少なく、ジャンクの提案をしないことです。また、残りのクエリに基づいて一致のセットをフィルタリングすることも確認してください（ユーザーが既に他の単語やフレーズを入力した場合）。 HTTPスクリプトが返された提案の数を制限していることを確認してください。ユーザーは通常、長いリストの候補から利益を得ることはできません。最も有用なものがトップになるように、提案をランク付けするためのアルゴリズムを作成します。最後に、助けになるよりも気を散らすような提案をしないように非常に注意してください。ユーザーに先行入力を促す場合は、検索や発想の邪魔になるので、ユーザーが望むものを手に入れることができない検索フレーズを提案する場合は、中断しないでください。私はそれをあまりにも頻繁に、主要なウェブサイトでさえ見た。機能の使用状況を測定し、それを時間の経過とともに調整したり、ユーザーの気を散らしている場合は削除したりしない限り、先送りはしないでください。

喜んで助けてください！

Answer 2

あなたはあなたの提案を入力するために範囲索引を使用していると言いますが、単語辞典も使用できます。ワードレキシコンは、要素（またはjsonプロパティ）全体の値ではなく、トークン化された文字データに基づく提案を生成します。それを調べる価値があるかもしれません。

また、ワイルドカードに言及しているので、恐らくcts:value-matchが関心があります。これは範囲索引からの値（単語ではない）で実行されますが、ワイルドカード式を入力として受け取ります。実際のコンテンツをプルアップして処理する必要があるスニペットアプローチよりもはるかに優れたパフォーマンスを発揮します。

HTH！