Requête Solr (q) ou requête filter (fq))
j'ai un index Solr de ~1 mil produit. J'ai aussi tout un tas de filtres UI tels que, Catégories, onglets, gammes de prix, tailles, couleurs, et quelques autres filtres.
est-ce la bonne façon de faire que le q sélectionne tout (q=\*:\*) alors que tous les autres filtres dans la fq? exemple:
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])
pour moi, tout, des catégories aux companyIds, des couleurs et des tailles, etc ne sont que des filtres. Aucun problème de performance dans la croissance future avec cette approche ? Devrais-je poser quelques questions dans le q, lesquelles ?
Merci,
3 ответов
il est préférable d'utiliser la requête Filter plutôt que la requête normale dans la mesure du possible.
FilterQuery est capable de profiter de la FilterCache, ce qui serait un énorme gain de performance en comparaison à vos requêtes.
je regarde les points suivants au sujet d'un champ afin de décider:
- 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.
- 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.
- 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>
Autres questions sur