Consulta de Solr (q) o consulta de filtro (fq)

Question

Tengo un índice de Solr de documento de producto de ~ 1 mil. También tengo un montón de filtros UI como categorías, pestañas, rangos de precios, tamaños, colores y algunos otros filtros.

¿Es la manera correcta de tener q seleccionando todo (q=\*:\*) mientras que todos los demás filtros en la fq? ejemplo:

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])

Para mí, todo de categorías para companyIds, de colores y tamaños, etc son sólo filtra. Cualquier problema en el rendimiento en el crecimiento futuro con este enfoque? ¿Debo poner algunas de las consultas en la q, cuáles?

Gracias,

Answer 1

Es preferible utilizar consulta de filtro sobre consulta normal siempre que sea posible.

FilterQuery puede aprovechar el FilterCache, lo que supondría un gran aumento del rendimiento en comparación con sus consultas.

Answer 2

La forma en que uso q y fq. Solicito la búsqueda de texto completo en q y todos los filtros en fq. Digamos que tiene campo palabra clave que su va a tener búsqueda de texto completo con los campos como se define en el esquema con 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"/> 

Mi consulta se vería

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

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

Como sugirió digitaljoel, si tiene que consultar múltiples campos, entonces sería mejor usar múltiples fq (consulte la consulta anterior) en lugar de usar AND y OR con q

Nota: en mi caso q por defecto se refiere al campo de palabras clave como se define en 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> 

Answer 3

me gustaría ver en los siguientes puntos sobre un campo a fin de decidir:

1. ¿Tiene su campo un puntaje de refuerzo fijo o necesita puntuación para este campo? En caso afirmativo, póngalo en consulta, porque como se mencionó anteriormente, la consulta de filtro no usa puntajes.
2. ¿Las condiciones de este campo se utilizan con frecuencia? Si es así, de nuevo, como se dijo antes, la memoria caché del filtro puede dar una gran ventaja, pero si no, puede ser aún más lenta.
3. ¿Es constante su índice? Esto es similar al # 2. Si su índice se actualiza con frecuencia, el uso de consultas de filtro puede convertirse en un cuello de botella en lugar de aumentar el rendimiento.

Algunas notas sobre el n. ° 3: En mi experiencia, tenía un gran índice que se llenaba con nuevos documentos cada pocos segundos y el autoSoftCommit también se configuraba en unos pocos segundos. Durante los commits suaves se abrió un nuevo buscador que invalidaba los cachés. Entonces, lo que realmente estaba sucediendo, la proporción de aciertos del filtro era casi siempre 0. Puedo decir más: me he dado cuenta de que la ejecución de la primera consulta de filtro es más costosa que la ejecución de una consulta con todas esas condiciones de filtro movidas a "q" en lugar de "fq". Por ejemplo, mi consulta tardó 1 segundo con 5 consultas de filtro (sin acierto de caché) y 147 ms cuando moví todas las condiciones "fq" a la consulta principal con "Y". Pero, por supuesto, cuando detuve las actualizaciones de índice, las mismas consultas de filtro tomaron 0ms porque se usó la memoria caché. Entonces esto es algo a considerar.

también algunos otros puntos de su pregunta:

• tratar de no utilizar comodines en la consulta. Afecta significativamente el rendimiento. Por lo tanto, en lugar de ":" Sugeriría utilizar una condición que es menos constante por solicitud (más constante por solicitud que no necesita puntaje que desea poner en "fq")
• Rango También es mejor evitar las búsquedas (si es posible). Y las búsquedas de rango con comodines aún más. Se trata de sus "endShipDays: [* TO 7]". Por ejemplo, usar "endShipDays: (1 2 3 4 5 6 7)" sería más efectivo, pero es solo un ejemplo, hay muchas maneras.

Espero que ayude.