2016-06-28 29 views
0

私は、非常に大きなドキュメントセットの検索を処理するためにSolrを使用しています。ファセットとフィルタを使用した複雑なクエリでパフォーマンスの問題が発生します。 これは、いくつかのデータを取得するために使用Solrのクエリです:Solrパフォーマンスの問題

フル要求のSolr:http://host/solr/discovery/select?q=& FQ =ドメイン%3Acom + OR +ホスト%3Acom + OR + public_suffix%3Acom & FQ = crawl_date%3A%5B2000-01 3DCrawl_year%7Dcrawl_year%3A%282000%29 & fq =%7B%21tag%3Dpublic_suffix%7Dpublic_suffix%3A %28com%29 &開始= 0 &行= 10 &ソート=スコア+ DESC & FL =% 2Cscore & HL =真& hl.fragsize = 200 & hl.simple.pre =%3Cstro NG%3E & hl.simple.post =%3C%2Fstrong%3E & hl.snippets = 10 & hl.fl =コンテンツ& hl.mergeContiguous = falseを& hl.maxAnalyzedChars = 100000 & hl.usePhraseHighlighter =真&面=真& facet.mincount = 1 & facet.limit = 11 & facet.field =%7B%21ex%3Dcrawl_year%7Dcrawl_year & facet.field =%7B%21ex%3Ddomain%7Ddomain & facet.field =%7B%21ex%3Dpublic_suffix% 7Dpublic_suffix & facet.field =%7B%21ex%3Dcontent_language%7Dcontent_language & facet.field =%7B%21ex%3Dcontent_type_norm%7Dcontent_type_norm & shards = shard1 "

約50000件のドキュメントでこのクエリを使用すると約10秒かかりますが、2億件のドキュメントをホスト上で試してみると約4分かかります。私は自然であることを知っています。ホストではかなり長い時間がかかるでしょうが、誰かが同じ問題を抱えていて、より速い結果を得ることができたのだろうかと思います。私が2つのシャードを使用していることを知っている。

あなたの回答を待っています。

+0

Solrのどのバージョンですか?あなたはおそらくあなたのクエリがあなたと働いていると示しているものに非常によく似て作成された[Solr sparse faceting](https://tokee.github.io/lucene-solr/)を見たいと思うでしょう。 – MatsLindh

答えて

0

あなたは、日付範囲、ハイライト、ファセット、および分散検索など、多数の複雑なことを一度に行います。 (非Solrcloudのように見えます)

まだ、50k-docインデックスの10秒は私にとってはとても遅く感じられます。選択的にを試してください。の検索結果を削除して、どの部分が遅くなっているのかを特定し、それに集中できるかどうかを確認してください。私は、たとえ多くの文書にマッチしたとしても、より簡単なクエリーを見つけることができると期待しています。

いずれにせよ、そこに役立つヒントがたくさんありますが、#1パフォーマンスの問題は通常、特に大規模な索引のために、十分なメモリを持っていないhttps://wiki.apache.org/solr/SolrPerformanceProblems#RAM

をチェックしてください。

0

solのセグメント数が多いほど、クエリ応答が悪くなるのを確認してください solrConfig.xmlにマージファクタを設定していないと、おそらく40個のセグメントが悪い新しいドキュメントが追加されていない場合に応じ あなたのマージ係数を設定し、クエリの応答時間 はそれを2

を設定MergeFactorの MergeFactorのは、おおよそのセグメント数を決定します。 mergeFactorの値は、Luceneに、同じセグメントを1つのセグメントにマージする前にいくつのセグメントを構築するかを指示します。これは、数字のシステムの基盤と考えることができます。 たとえば、mergeFactorを10に設定すると、インデックスに追加された1000(またはmaxBufferedDocs)のドキュメントごとにディスクに新しいセグメントが作成されます。サイズ1000の10番目のセグメントが追加されると、10個はすべて10,000個の1つのセグメントにマージされます。このような10,000のサイズのセグメントが10個追加されると、100,000個のドキュメントを含む単一のセグメントにマージされます。したがって、いつでも、各インデックスサイズには9つ以上のセグメントが存在しません。 これらの値は、solrconfig.xmlのmainIndexセクション(indexDefaultsセクションを無視)に設定されています。 MergeFactorのトレードオフ 高い値のマージ因子(例えば、25): プロ:、あまり頻繁にマージ:一般 コンインデックス速度を向上させることができますより多くのインデックスファイルを含むコレクションが生成され、検索が遅くなる可能性があります。 値の小さいマージファクタ(例:2): プロ:検索のスピードアップを図るインデックスファイルの数が少なくなりました。 欠点:より多くのセグメントマージがインデックス作成の速度を低下させます。

関連する問題