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

solr query

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 otros filtros en el 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, desde categorías hasta empresas, desde colores y tamaños, etc., son solo filtros. 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

La forma en que uso q y fq . Aplico búsqueda de texto completo en qy todos los filtros en fq . Supongamos que tiene una palabra clave de campo que va a tener una búsqueda de texto completo con los campos definidos en su 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 como

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

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

Como Digitaljoel sugirió, 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 a la palabra clave de campo 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 2

Es preferible usar Filter Query sobre Query normal siempre que sea posible.

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

Answer 3

Me gustaría ver los siguientes puntos sobre un campo para decidir:

1. ¿Su campo tiene 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. ¿La condición para este campo se usa 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. ¿Tu índice es constante? 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 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 sucedía, la proporción de aciertos de filtro era casi siempre 0. Puedo decir más: me he dado cuenta de que 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 para su pregunta:

• Intente nunca usar comodines en su consulta. Afecta significativamente el rendimiento. Por lo tanto, en lugar de " : " Sugeriría usar una condición que sea menos constante por solicitud (la más constante por solicitud que no necesite puntaje que quiera poner en "fq")
• También es mejor evitar las búsquedas de rango (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 eso ayude.