Un FilterQuery SOLAMENTE almacena documentos IDS. Esto hace que sea muy rápido aplicar el filtro para incluir/excluir documentos. Buenos ejemplos de esto son al filtrar productos de búsqueda según el país, tipo de producto, disponibilidad, etc.
Una consulta normal puede realizar exactamente la misma función, pero tiene un sistema de puntuación muy complejo para determinar la "relevancia". Creo que la documentación indica que la puntuación solo se realiza en la consulta principal, no en la consulta de filtro. Esto también debería aumentar la velocidad de consulta.
Por lo tanto, puede preguntar para:
description:Kohler AND productType:Toilet
O puedo consultar para:
description:Kohler
with a FQ of productType:Toilet
Los resultados serían los mismos, pero los resultados serían diferentes. Además, si obtiene muchas consultas diferentes a lo largo del día que son para productType:Toilet
, FilterQuery se almacenará en caché haciendo que el tiempo de consulta general sea más rápido.
Entonces, por ejemplo, al indexar hay un aumento de término en "productType", los resultados pueden ordenarse de manera diferente si productType se establece en FilterQuery en lugar de la consulta principal, de modo que si está en la consulta, esos documentos con La puntuación más alta de ProductType estará en la parte superior, mientras que si está en una FilterQuery, los documentos con una puntuación más alta de productType podrían estar en la parte inferior porque la puntuación no se aplica puesto que está en una FilterQuery. ¿Te entiendo, verdad? – mrd3650
Correcto. Sin embargo, si coloca productType en la consulta principal como una cláusula AND, de todos modos no obtendría ningún otro tipo de producto. Entonces esto puede ser de valor limitado. Pero, lo que dijiste significa que entiendes cómo funciona. – rfeak
Sí, tiene razón, porque estaba asumiendo incorrectamente un FTS en tipo de producto también (por lo tanto, más de un tipo de producto podría ser devuelto, pero generalmente no hay FTS en * Tipo). Gracias. – mrd3650