問題タブ [lucene]

Lucene のロシア語サポートは非​​常に貧弱です。

RussianAnalyzer (lucene-contrib の一部) は非常に低品質です。

Snowball の RussianStemmer モジュールはさらに悪いです。明らかに、代わりに Unicode と KOI8-R の奇妙な組み合わせを使用する必要があると仮定して、Unicode 文字列内のロシア語のテキストを認識しません。

より良い解決策を知っていますか？

新しい Lucene インデックスのサイズを見積もるために使用できる既知の数式はありますか? インデックスを作成したいフィールドの数と、各フィールドのサイズを知っています。そして、いくつの項目が索引付けされるかを知っています。では、これらが Lucene によって処理されると、どのようにバイトに変換されるのでしょうか?

スコアではなく、Lucene.Net インデックスの特定のフィールドでクエリ結果を並べ替える方法を見つけました。必要なのは、インデックス化されているがトークン化されていないフィールドだけです。ただし、「a」や「the」などのストップワードを無視してそのフィールドをソートする方法がわかりません。たとえば、次の本のタイトルは次のように昇順でソートされます。

1. 帽子の中の猫
2. ホートンは誰かを聞く

そのようなことは可能ですか？

Lucene.Net 2.3.1.2 を使用しています。

Lucene用の（Java）蛍光ペン（Sandboxパッケージ内）をしばらく使用しています。ただし、これは検索結果の正しい用語の照合に関してはあまり正確ではありません。たとえば、2つの別々の単語を検索すると、結果の両方のコードフラグメントが強調表示されます。

ただし、より複雑なクエリではうまく機能しません。最も単純なケースでは、「Stack Overflow」などのフレーズクエリは、強調表示で発生するStackまたはOverflowのすべてに一致し、ユーザーにうまく機能していないという印象を与えます。

ここで修正を適用しようとしましたが、パフォーマンスに関する多くの警告があり、結局のところ、まったく使用できませんでした。パフォーマンスは、ワイルドカードクエリで特に問題になります。これは、強調表示が機能する方法によるものです。クエリ文字列とテキストを処理するだけでなく、Luceneのように解析して、Luceneが行ったすべての一致を検索します。残念ながら、これは、特定のワイルドカードクエリでは、大きなドキュメントの2000以上の句に一致するものを検索する可能性があり、単に十分な速度ではないことを意味します。

正確な蛍光ペンのより高速な実装はありますか？

私は、データベースに対するより良い検索機能のためのメカニズムを調べています。これは現在、大きなボトルネックになっています（データベースのパフォーマンスを低下させる長期的なクエリを引き起こします）。

上司は私にSolrを調べてほしいと思っていましたが、詳しく調べてみると、実際にはLucene自体との何らかのDB統合メカニズムが必要なようです。

Lucene FAQから、Hibernate Search、Compass、およびDBSightを推奨しています。

現在のテクノロジースタックの背景として、TomcatでストレートJSPを使用しており、Hibernateは使用せず、その上に他のフレームワークは使用していません... DB2データベースに対してストレートJava、JSP、およびJDBCを使用しています。

それを考えると、Hibernate Searchをシステムに統合するのは少し難しいかもしれませんが、そのような統合の後にHibernateを使用するオプションがあると便利かもしれません。

適切なツールを選択するのに役立つ可能性のある、これらのツールの1つ（または他の同様のLuceneベースのソリューション）を使用して共有できる経験はありますか？

これはFOSSソリューションである必要があり、理想的には、変更が行われたときにツールに通知するための余分な労力なしに、データベースからの変更でLuceneの更新を自動的に（効率的に）管理します（そうでない場合は、独自のLuceneソリューションをロールするだけでよいようです）良い）。また、1つのデータベース（+フェイルオーバー）を備えた複数のアプリケーションサーバーがあるため、すべてのアプリケーションサーバーのソリューションをシームレスに使用するのが簡単であると便利です。

私は現在も選択肢を検討し続けていますが、他の人の経験を活用することは本当に役に立ちます。

私は自分のプロジェクトでluceneを使用しています。ここに私の質問があります：多数のlikeステートメントとidまたはsthによる正確な検索を使用してsqlで実装された検索モジュール全体をluceneで置き換える必要がありますか、それともあいまい検索でluceneを使用する必要があります（つまり、全文検索を意味します） ）？

Lucene インデックスとインクリメンタル インデックスに対して、7 日ごとに完全な再インデックスを実行します (つまり、インデックスをゼロから作成します)。私たちのインデックスには約 700,000 のドキュメントがあり、完全なインデックスには約 17 時間かかります (これは問題ではありません)。

インクリメンタル インデックスを作成する場合、過去 2 時間以内に変更されたコンテンツのみをインデックスに登録するため、時間は大幅に短縮され、約 30 分ほどかかります。ただし、この時間の多く (おそらく 10 分) が IndexWriter.optimize() メソッドの実行に費やされていることに気付きました。

LuceneFAQは次のように述べています。

IndexWriter クラスは、インデックス データベースを圧縮してクエリを高速化する optimize() メソッドをサポートしています。ドキュメント セットの完全なインデックス作成を実行した後、またはインデックスの増分更新後に、このメソッドを使用することができます。増分更新によってドキュメントが頻繁に追加される場合は、最適化の余分なオーバーヘッドを回避するために、最適化を時々実行する必要があります。

...しかし、これは「頻繁に」が何を意味するのかを定義していないようです。最適化は CPU を集中的に使用し、非常に IO を集中的に使用します。最適化されていないインデックスでクエリを実行した場合のヒットはどのくらいですか (たとえば、50,000 のドキュメントが変更された 20 のインクリメンタル インデックスの後と比較して、完全な再インデックス後のクエリ パフォーマンスに関して特に考えています)。すべてのインクリメンタル インデックスの後に最適化する必要がありますか、それともパフォーマンス ヒットは価値がないのでしょうか?

Lucene でクエリの自動補完/提案を行う方法を探しています。私は少しグーグルで検索し、少し遊んでみましたが、私が見たすべての例はSolrでフィルターを設定しているようです. 私たちは Solr を使用しておらず、近い将来に Solr の使用に移行する予定もありません。Solr は明らかに Lucene をラップしているだけなので、それを行う方法があるに違いないと思います!

私は EdgeNGramFilter の使用を検討しましたが、インデックス フィールドでフィルターを実行し、トークンを取得してから、それらを入力されたクエリと比較する必要があることに気付きました...この 2 つは少しのコードにまとめられているので、助けていただければ幸いです。

私が探しているものを明確にするために（私はあまり明確ではないことに気づきました、申し訳ありません）-用語を検索するときに、提案されたクエリのリストを返すソリューションを探しています。検索フィールドに「inter」と入力すると、「internet」、「international」などの候補クエリのリストが表示されます。

ウェブサイトで検索機能を提供するためのあなたの好ましい方法は何ですか？現在、インデックスサービス/ SQL Serverフルテキスト検索よりもLucene.netを使用することを好みます（サーバー側を設定するものがないため）が、他にどのような方法が使用されていますか？

Lucene Java 2.3.2 を使用して、製品のカタログに検索を実装しようとしています。商品の通常のフィールドとは別に、「カテゴリー」と呼ばれるフィールドがあります。製品は複数のカテゴリに分類できます。現在、FilteredQuery を使用してすべてのカテゴリで同じ検索語を検索し、カテゴリごとの結果数を取得しています。

これにより、結果を表示するためにクエリごとに 20 ～ 30 回の内部検索呼び出しが発生します。これにより、検索が大幅に遅くなります。Lucene を使用して同じ結果をより速く達成する方法はありますか?