31

私は約1milの製品ドキュメントSolrインデックスを持っています。また、カテゴリ、タブ、価格帯、サイズ、色、その他のフィルタなど、多数のUIフィルタがあります。

(q=\*:\*)fq内の他のすべてのフィルターを使用して、qにすべてを選択させるのは正しい方法ですか？例：

fq=(catid:90 OR catid:81) AND priceEng:[38 TO 40] AND (size:39 OR size:40 OR size:41 OR size:50 OR size:72) AND (colorGroup:Yellow OR colorGroup:Violet OR colorGroup:Orange ... AND (companyId:81 OR companyId:691 OR companyId:671 OR companyId:628 OR companyId:185 OR companyId:602 OR ... AND endShipDays:[* TO 7])

私にとって、カテゴリからcompanyIds、色やサイズなど、すべてが単なるフィルターです。このアプローチによる将来の成長におけるパフォーマンスの問題はありますか？クエリのいくつかをqに入れる必要がありますか？

ありがとうございました、

4

4 に答える 4

52

可能な限り、通常のクエリよりもフィルタクエリを使用することをお勧めします。

FilterQueryはFilterCacheを利用できます。これは、クエリと比較してパフォーマンスが大幅に向上します。

于 2012-07-24T09:09:03.780 に答える
10

決定するために、フィールドに関する次の点を確認します。

  1. あなたのフィールドには固定のブーストスコアがありますか、それともこのフィールドのスコアが必要ですか？はいの場合、それをクエリに入れます。前述のように、フィルタクエリはスコアを使用しないためです。
  2. このフィールドの条件は頻繁に使用されていますか？はいの場合（前に述べたように）、フィルターキャッシュは大きな利点をもたらす可能性がありますが、そうでない場合はさらに遅くなる可能性があります。
  3. あなたのインデックスは一定ですか？これは＃2に少し似ています。インデックスが頻繁に更新される場合、フィルタークエリの使用は、パフォーマンスを向上させるのではなく、ボトルネックになる可能性があります。

＃3に関する注意事項：私の経験では、数秒ごとに新しいドキュメントが読み込まれる大きなインデックスがあり、autoSoftCommitも数秒に設定されていました。ソフトコミット中に、キャッシュを無効にしていた新しいサーチャーが開かれました。つまり、実際に起こったことは、フィルターのヒット率がほぼ常に0であったことです。詳細を知ることができます。最初のフィルタークエリの実行は、すべてのフィルター条件を「q」ではなく「q」に移動したクエリの実行よりもコストがかかることがわかりました。 fq」。たとえば、私のクエリは5つのフィルタークエリ（キャッシュヒットなし）で1秒かかり、すべての「fq」条件を「AND」でメインクエリに移動すると147ミリ秒かかりました。しかしもちろん、インデックスの更新を停止すると、キャッシュが使用されたため、同じフィルタークエリに0ミリ秒かかりました。したがって、これは考慮すべきことです。

また、あなたの質問に対する他のいくつかのポイント：

  • クエリでワイルドカードを使用しないようにしてください。パフォーマンスに大きく影響します。したがって、「：」の代わりに、リクエストごとの定数が少ない1つの条件を使用することをお勧めします（「fq」に付けたいスコアを必要としないリクエストごとのほとんどの条件）
  • 範囲検索も（可能であれば）避ける方がよいでしょう。また、ワイルドカードを使用した範囲検索はさらに多くなります。それはあなたの「endShipDays：[*TO7]」についてです。たとえば、「endShipDays：（1 2 3 4 5 6 7）」を使用するとより効果的ですが、これは単なる例であり、多くの方法があります。

それが役に立てば幸い。

于 2016-02-12T19:57:16.737 に答える
5

qとfqの使い方。qに全文検索を適用し、 fqにすべてのフィルターを適用します。copyFieldを使用してスキーマで定義されたフィールドを使用して全文検索を行うフィールドキーワードがあるとします。

<copyField source="id" dest="keyword"/>
<copyField source="category" dest="keyword"/>
<copyField source="product_name" dest="keyword"/>
<copyField source="color" dest="keyword"/>
<copyField source="location" dest="keyword"/>
<copyField source="price" dest="keyword"/>
<copyField source="title" dest="keyword"/>
<copyField source="description" dest="keyword"/>

私のクエリは次のようになります

/select?q={keyword}&fq=category:fashion&fq=location:nyc

/select?q=jeans&fq=category:fashion&fq=location:nyc

digitaljoelが提案したように、複数のフィールドをクエリする必要がある場合は、 qでANDおよびORを使用する代わりに、複数のfq（上記のクエリを参照）を使用することをお勧めします。

注：私の場合、qデフォルトはsolrconfig.xmlで定義されているフィールドキーワードを指します

<requestHandler name="/select" class="solr.SearchHandler">
<!-- default values for query parameters can be specified, these
     will be overridden by parameters in the request
  -->
 <lst name="defaults">
   <str name="echoParams">explicit</str>
   <int name="rows">10</int>
   <str name="df">keyword</str>
 </lst>
于 2015-03-23T07:32:52.453 に答える
2

クエリについて考え、スコアリングする必要がなく、繰り返し可能なものをすべてfqパラメータに入れます。そうすれば、サーチャーを開く間にSolrノードにヒットする連続したクエリは、FilterCacheに格納されている情報を再利用できます。

フィルタキャッシュは、一意のフィルタをフィルタのキーとして格納します。値はビットの配列であり、配列の各エントリは、特定のドキュメントが特定のフィルタと一致するかどうかを示します。そうすれば、次のクエリにフィルターを再適用するのは非常に簡単です。しかし、もちろん、あなたはスコアリング機能を見逃しています。

fqあなたのクエリを見るとき、私はそれらの行の中で何か、複数の値を使用することによって、それを少し単純化します：

fq=(catid:90 OR catid:81)
fq=priceEng:[38 TO 40]
fq=(size:39 OR size:40 OR size:41 OR size:50 OR size:72)
fq=(colorGroup:Yellow OR colorGroup:Violet OR colorGroup:Orange  ... ) 
fq=(companyId:81 OR companyId:691 OR companyId:671 OR companyId:628 OR companyId:185 OR companyId:602 OR ... ) 
fq=endShipDays:[* TO 7])

フィルタは加算的であるため、クエリは同じ結果を返しますが、少なくとも私にとっては管理が簡単です:)

于 2020-03-25T17:26:43.580 に答える