2012-05-01 3 views
6

Attualmente sto eseguendo una coppia client/server Solr che funziona correttamente.Il modo corretto di aggiungere parametri di query personalizzati in Solr

Tuttavia, in alcuni casi, la query di filtro (fq parametri) che viene inviato al Solr è abbastanza grande (può essere migliaia di caratteri) e non possono essere tagliati giù. Poiché l'analisi delle query richiede only a fraction of the overall time, voglio provare a zippare questa parte di query e inviarla a Solr.

Stavo pensando di modificare il client, quindi anziché fq utilizza un altro parametro (ad esempio zfq). Solr può quindi decidere - se riceve zfq, lo utilizza e decodifica i dati in fq. Altrimenti dovrebbe comportarsi come al solito.

Qual è il modo standard per ottenere quanto sopra? Sembra che ci sia SearchHandler, requestHandler, <queryParser (entrambi in solrconfig.xml) e molti altri e non sono abbastanza sicuro di quale sia il meno invadente. Sono abbastanza fiducioso con Lucene/Tomcat ma non so molto delle strutture dati Solr.

+2

Migliaia di caratteri in un singolo 'fq' non sembrano giusti. Invece di cercare di aggirare le limitazioni, chiediti * perché * stai colpendo quelle limitazioni. Descrivi il tuo problema * reale *. –

+0

Il vero problema non rientra negli obiettivi di questa domanda. Ma se vuoi sentirlo - certo, nessun problema! La lunghezza deriva dal modo in cui vengono implementate le autorizzazioni. Per i clienti che dispongono di ampi set di autorizzazioni, la query di filtro ha il seguente aspetto: "*: * -category: 1 AND -category: 2 AND ... -category: N". Quale è un candidato perfetto per la compressione mentre il modello si ripete. – mindas

+0

hai visto questo problema JIRA sulla sicurezza a livello di documento? https://issues.apache.org/jira/browse/SOLR-1834 –

risposta

0

Avete pensato di utilizzare questa sintassi -categoria: (1 2 3 4 ... N). Questo dovrebbe ridurre la corda del 90%. Meglio di zippare.

+0

Vorrei che i punti di taglie non fossero scaduti, ci è voluto un po 'troppo tempo per ottenere la risposta postata :( – mindas

1

Puoi rendere il tuo contenitore Solr estremamente lungo: Tomcat here, Jetty here.

Se lo fq s ha alcuni valori predefiniti, è possibile creare un parser di query che lo include per impostazione predefinita.

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

ma sono d'accordo con Mauricio Scheffer per un design migliore.

+0

Il 'fq' non rimane mai lo stesso quindi renderlo predefinito non aiuterà. La mia vera domanda è come estendere Solr e non come risolvere questo problema. – mindas

+0

Cattiva presunzione quindi :-) Ma non aumenterebbe la lunghezza dell'intestazione (e quindi la lunghezza dell'URL) del tuo contenitore App per risolvere il tuo problema? – aitchnyu

+0

L'ho già fatto, ma voglio sperimentare le query di archiviazione e vedere se questo aiuta a ridurre la latenza. – mindas

Problemi correlati