非常に遅いSolrのパフォーマンス

Question

を強調私は約10ギガバイトの元のサイズで約630Kの文書が含まれて構成されてSolr 4.4.0コアを持っています。各フィールドは、照会および強調表示の目的で、テキストフィールドにコピーされます。私は強調せずに検索を実行すると、結果はおよそ100ミリ秒に戻ってくるが、ハイライト表示をオンにすると、同じクエリが10-11秒かかります。私はまた、同じ条件のため以降のクエリが同じ10〜11秒程度かかり続けたことに気づきました。

<field name="text" type="text_general" indexed="true" stored="true" 
    multiValued="true" 
    omitNorms="true" 
    termPositions="true" 
    termVectors="true" 
    termOffsets="true" /> 

送信されるクエリは次のよう

http://solrtest:8983/solr/Incidents/select?q=error+code&fl=id&wt=json&indent=true&hl=true&hl.useFastVectorHighlighter=true 

に似ていますが、次のようにフィールドの

私の初期設定は、すべて私の研究は、なぜハイライトについて何ら手掛かりを提供しないように思われましたパフォーマンスはとても悪いです。気まぐれで、私はomitNorms =真属性が効果を持つことができるかどうかことを決めた、私は、テキストフィールドを変更されたデータを一掃し、ゼロから再ロード。

<field name="text" type="text_general" indexed="true" stored="true" 
    multiValued="true" 
    termPositions="true" 
    termVectors="true" 
    termOffsets="true" /> 

奇妙なことに、これは問題を解決するように思われました。ハイライトとの最初のクエリでは、以下100ミリ秒を取って後続の問合せで2-3秒を取りました。我々はomitNorms =場所で真をしたいので

しかし、私の恒久的な解決策は、「テキスト」フィールドのコピー、なしの属性を持つ1つずつを持っていることでした。 1つのフィールドに対してクエリを実行し、他のフィールドに対してハイライト表示するというアイデアがありました。だから今スキーマは

<field name="text" type="text_general" indexed="true" stored="true" 
    multiValued="true" 
    omitNorms="true" 
    termPositions="true" 
    termVectors="true" 
    termOffsets="true" /> 

<field name="text2" type="text_general" indexed="true" stored="true" 
    multiValued="true" 
    termPositions="true" 
    termVectors="true" 
    termOffsets="true" /> 

のように見えて、再び

http://solrtest:8983/solr/Incidents/select?q=error+code&fl=id&wt=json&indent=true&hl=true&hl.fl=text2&hl.useFastVectorHighlighter=true 

を次のようにクエリは、データがクリアされ、同じ630K書類を再ロードしているが、この時間は、インデックスのサイズは約17 GBです。 （期待されるように「テキスト」フィールドの内容が重複しているため。）

問題は、パフォーマンスの数値は、元10-11秒にそれぞれ実行していることです。 omitNormsを最初に削除したのは、偶然だったのですか、それとも何か他のことが起こっています。私は、CPUのサンプルをキャプチャするjVisualVMを使用し

は

org.apache.lucene.search.vectorhighlight.FieldPhraseList.<init>() 8202 ms (72.6%) 
org.eclipse.jetty.util.BlockingArrayQueue.poll()      1902 ms (16.8%) 

は、私が54％と世論調査のような低いinitメソッドを見ているCPUのほとんどを使用して、次の2つの方法を示しています...何見当がつかない30％もの高さ。

アイデア？ボトルネックを追跡するために私が見ることができる他の場所？

おかげ

更新

私は、同じデータセットが、異なる構成でテストの束を行い、ここで私が見つけたものを...私は私の調査結果を理解していないがあるしています。

• スピーディハイライト性能がomitNormsが真に設定されていないことが必要です。
• しかし、これは、と同じフィールド（つまり、df = hl.fl）に対してクエリとハイライトの両方を実行した場合にのみ当てはまります。これは、 。 （理由も分かりませんが）
• ただし、スキーマに存在するデフォルトののテキストフィールドに対して行われた場合のみです。

ここ

私がテストした方法です - >

• テストはほとんどすべてのフィールドがいくつかでは、多値テキストフィールド
• にコピーされたおよそ525,000文書
• に反対しましたテストでは、フィールドのほとんどすべては、複数値のテキスト2フィールドにコピーされました（このフィールドはと同じですそれを除いトンは反対omitNormsデータフォルダが削除された、
• 設定が変更されたたびに、Solrのインスタンスが停止した設定を持っていた、とインスタンスはバックアップ私が見つけた何

開始されました - - > =真は存在、パフォーマンスはBだっただけテキストフィールドを使用した

• とomitNormsました広告（10秒の応答時間）だけテキストフィールドを使用した
• とomitNorms =真が存在していなかった、パフォーマンスは素晴らしい（サブ秒の応答時間）だったが
• テキストがをしましたはomitNorms =真とテキスト2、クエリがサブ秒の時間で返さテキスト、に対して他のすべての COMBINAを強調ウィットでしたを持っていません10〜30秒の応答時間となりました。
• テキストは真omitNorms =とを持っていたテキスト2はないをした、7-10秒で返さ強調表示とクエリのすべての組み合わせ。

私はサイコー混乱しています....

Answer 1

私はこれは少し日付であることを知っているが、私は同じ問題に遭遇したと我々のアプローチでチャイムたいと思っていました。

バイナリドキュメントの束からテキストを索引付けしています。ソルがドキュメントとテキストについてのメタデータを維持する必要があります。ユーザーは、コンテンツ内のメタデータと全文検索に基づいてドキュメントを検索するだけでなく、関連するコンテンツのハイライトやスニペットも表示する必要があります。ハイライト/スニペットのコンテンツが各文書（e。2ページの代わりに50ページ）内にさらに配置されていると、パフォーマンスの問題が悪化します。

各文書を複数のソルレコードに分割する必要がありました。コンテンツフィールドの長さに応じて、それをより小さなチャンクに分割し、メタデータ属性を各レコードにコピーし、各レコードにドキュメントごとの一意のIDを割り当てます。その後、クエリ時に、これらすべてのレコードのコンテンツフィールドを検索し、割り当てられたその一意のフィールドでグループ化します。コンテンツフィールドが小さいので、Solrは各コンテンツフィールドに加えてエンドユーザーの立場から深く入り込む必要はありませんが、これは完全に透過的です。それは私たちのために少しの索引付けのオーバーヘッドを追加します。

さらに、この方法を選択した場合、2秒の境界にフレーズマッチがあると正しく戻されるように、各「サブ文書」の間に少しずつ秒を重ねることを検討することをお勧めします。

希望します。