0

今後数か月以内に、SQL 全文検索から Lucene (SOLR スタック) 検索に切り替えます。ここでの戦略を理解する上での最後の問題は、検索プラットフォームの現在の部分を複製することです。

まず、問題を説明するための用語をいくつか紹介します。私たちのサイトにはたくさんのドキュメントがあります。人々はそれらのドキュメントを「追加」し、それらのドキュメントを「お気に入り」にし、それらのドキュメントを「読む」などするかもしれません。特定のユーザーのそのようなドキュメントの結合を「個人ドキュメント」と呼びましょう。一部のドキュメントは公開されており、一部は非公開であるため、ログインしたユーザーのみが表示できます。

現在、特定のユーザーの「個人的な」ドキュメントを常に検索リストの最初に表示する重み付け機能があります。これは通常の順序よりも優先されます (ただし、ドキュメントは結果セットで有効でなければなりません。重要度の低い他のドキュメントよりも上位にランク付けされるだけです)。SQL では、スコアを返すユーザー定義関数を使用することでこれを実現できますが、これはユーザーによって異なります。

たとえば Facebook では、"Joe" と入力すると、最初に知っているすべての Joe が検索され、次に条件に一致する他の Joe が検索されます。"Joe" を検索すると、Joe を検索した場合とは異なる順序付きセットが返されます。

Lucene/SOLR の世界では、私が理解しているように、2 つの個別のクエリが効果的に UNION 化されない限り、このようなユーザー中心のドキュメントの重み付けを行う方法を理解できません (リレーショナルではないことはわかっていますが、その考えは理解できます)。 )。何百万ものユーザーと何十万ものドキュメントがあります。ユーザーがログインしている場合、すべての検索で「そのユーザーのドキュメント」が最初に表示され、次に残りのすべてのドキュメントが表示されるようにします。いずれの場合も、元の検索に一致するドキュメントのみを検索結果に表示する必要があります。つまり、ランク順について話しているだけです。

このユーザー定義関数機能を再現するための戦略を考えられますか?

4

1 に答える 1

1

この特定のドキュメントがジムに属していることを示すフィールドを各ドキュメントに含める余裕はありますuser123Doc:1か(例)。はいの場合、結果セットを。で並べ替えることで解決できます{user123Doc, score, ...}

または、この情報をLuceneに保存したくない場合は、これを他の場所(データベースなど)に保存してFieldComparator、これらの値で機能するように実装できます。詳細については、こちらをご覧ください

于 2013-01-29T10:22:41.573 に答える