2012-05-01 9 views
6

Actualmente estoy ejecutando un par de cliente/servidor Solr que funciona bien.La forma correcta de agregar un parámetro de consulta personalizado en Solr

Sin embargo, en algunos casos, la consulta de filtro (parámetro fq) que se envía a Solr es bastante grande (puede tener miles de caracteres) y no se puede recortar. Como el análisis de consultas lleva only a fraction of the overall time, quiero experimentar con comprimir esta parte de consulta y enviarla a Solr.

Estaba pensando en modificar el cliente por lo que en lugar de fq utiliza otro parámetro (por ejemplo, zfq). Solr puede decidir: si recibe zfq, lo usa y decodifica los datos en fq. De lo contrario, debería comportarse como de costumbre.

¿Cuál es la forma estándar de lograr lo anterior? Parece que hay SearchHandler, requestHandler, <queryParser (ambos en solrconfig.xml) y muchos otros y no estoy muy seguro de qué es lo menos intrusivo. Estoy bastante seguro con Lucene/Tomcat pero no sé mucho sobre las estructuras de datos de Solr.

+2

Miles de caracteres en un solo 'fq' no parecen correctos. En lugar de tratar de evitar las limitaciones, pregúntese a usted mismo por qué * está superando esas limitaciones. Describe tu problema * real *. –

+0

El verdadero problema está fuera del alcance de esta pregunta. Pero si quieres escucharlo, claro, ¡no hay problema! La longitud proviene de cómo se implementan los permisos. Para los clientes que tienen conjuntos de permisos amplios, la consulta de filtro se ve así: "*: * -category: 1 AND -category: 2 AND ... -category: N". Que es un candidato perfecto para la compresión a medida que el patrón se repite. – mindas

+0

¿ha visto este problema JIRA sobre la seguridad a nivel de documento? https://issues.apache.org/jira/browse/SOLR-1834 –

Respuesta

0

¿Ha pensado en usar esta sintaxis -category: (1 2 3 4 ... N). Eso debería reducir la cuerda en un 90%. Mejor que comprimir.

+0

Ojalá los puntos de recompensa no hubieran expirado, tomó un poco demasiado tiempo para obtener la respuesta publicada :( – mindas

1

Puede hacer que su contenedor Solr tome direcciones extremadamente largas: Tomcat here, Jetty here.

Si el fq s tiene algunos valores predeterminados, puede crear un analizador de consultas que lo incluya de forma predeterminada.

<requestHandler name="for_some_queries" class="solr.SearchHandler" default="true"> 
    <!-- default values for query parameters --> 
    <lst name="defaults"> 
     <str name="echoParams">explicit</str> 
     <str name="fq">MY VERY LONG FQ</str> 
    </lst> 
    </requestHandler> 

pero estoy de acuerdo con Mauricio Scheffer, para un mejor diseño.

+0

El 'fq' nunca se mantiene igual, por lo que no funcionará. Mi verdadera pregunta es cómo extender Solr y no cómo resolver este problema. – mindas

+0

Mala suposición, entonces :-) Pero no aumentaría la longitud del encabezado (y por lo tanto la longitud de la URL) de su contenedor de aplicaciones para resolver su problema? – aitchnyu

+0

Ya lo he hecho, pero quiero experimentar con las consultas de archivo y ver si esto ayuda a reducir la latencia. – mindas

Cuestiones relacionadas