Requête Solr (q) ou requête filter (fq))

je regarde les points suivants au sujet d'un champ afin de décider:

1. votre champ a-t-il un score de boost fixe ou avez-vous besoin d'un score pour ce champ? Si oui, mettez-le dans la requête, parce que comme mentionné ci-dessus, la requête de filtre n'utilise pas les scores.
2. la condition pour ce champ est-elle utilisée fréquemment? Si oui-encore une fois, comme dit précédemment, le cache de filtre peut donner un avantage énorme, mais si non - il peut être encore plus lent.
3. votre indice est-il constant? C'est un peu comme le #2. Si votre index est mis à jour fréquemment, l'utilisation de requêtes filtrantes peut devenir un goulot d'étranglement au lieu de donner un coup de pouce aux performances.

quelques notes sur le #3: d'après mon expérience, j'avais un gros index qui était rempli de nouveaux docs toutes les quelques secondes et autoSoftCommit était réglé sur quelques secondes aussi. Au cours de commits doux, un nouveau chercheur a été ouvert, ce qui invalidait les caches. Donc ce qui se passait vraiment, le taux de succès des filtres était presque toujours de 0. Je peux dire de plus: j'ai j'ai compris que la première requête de filtre est plus chère que l'exécution d'une requête avec toutes ces conditions de filtre déplacées à "q" au lieu de "fq". Par exemple, ma requête a pris 1 seconde avec 5 requêtes de filtrage (pas de mise en cache) et 147ms quand j'ai déplacé toutes les conditions "fq" dans la requête principale avec "et". Mais bien sûr, quand j'ai arrêté les mises à jour d'index, les mêmes requêtes de filtre ont pris 0ms parce que le cache a été utilisé. Donc, c'est quelque chose à considérer.

Aussi quelques autres points pour votre question:

• Essayez de ne jamais utiliser des caractères génériques dans votre requête. Il affecte de manière significative les performances. Donc au lieu de ":" je vous suggérons d'utiliser une seule condition qui est moins constante-par-requête (la plus constante-par-requête qui n'ont pas besoin de partition que vous souhaitez mettre à "fq")
• faire des recherches également préférable d'éviter (si possible). Et les recherches de gamme avec des jokers encore plus. Il s'agit de votre "endShipDays:[* à 7]". Par exemple, en utilisant " endShipDays: (1 2 3 4 5 6 7) " serait plus efficace, mais ce n'est qu'un exemple, il y a plusieurs façons.

j'Espère que ça aide.

La façon dont j'utilise q et fq. J'applique la recherche de texte intégral sur q et tous les filtres sur fq. Disons que vous avez de domaine mot clé que vous allez avoir la recherche plein texte avec les champs définis dans votre schéma avec 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"/>

ma requête ressemblerait à

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

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

comme digitaljoel suggéré, si vous devez interroger plusieurs champs, alors il serait préférable d'utiliser plusieurs fq (se référer à au lieu d'utiliser et et ou avec q

Note: dans mon cas q par défaut réfère à champ mot clé tel que défini dans 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>