2014-07-25 6 views
5

Sto riscontrando problemi di prestazioni durante l'esecuzione di una query che utilizza sia lo slop che il vettore dei fatti Evidenziatore. È interessante notare che il problema di prestazioni scompare quando si esegue la stessa query con l'evidenziatore semplice e non sono sicuro del motivo per cui questo è il caso.ElasticSearch e performance di evidenziazione - Evidenziatore vettoriale semplice o veloce

Ecco i metadati per il campo da ricercare:

contents: { 
    store: true 
    search_analyzer: mySearchAnalyzer 
    term_vector: with_positions_offsets 
    type: string 
} 

La seguente interrogazione, che utilizza l'evidenziatore infatti vettore, richiede più di 60 secondi:

{ 
    "size": 500, 
    "query": { 
    "query_string": { 
     "query": "\"CATERPILLAR FINANCIAL SERVICES ASIA PTE LTD\"~5", 
     "fields": [ 
     "contents" 
     ], 
     "default_operator": "and", 
    } 
    }, 
    "highlight": { 
    "fields": { 
     "contents": {} 
    } 
    } 
} 

Tuttavia, se cambio la query per utilizzare l'analizzatore semplice, quindi richiede solo pochi millisecondi:

{ 
    "size": 500, 
    "query": { 
    "query_string": { 
     "query": "\"CATERPILLAR FINANCIAL SERVICES ASIA PTE LTD\"~5", 
     "fields": [ 
     "contents" 
     ], 
     "default_operator": "and", 
    } 
    }, 
    "highlight": { 
    "fields": { 
     "contents": {"type" : "plain"} 
    } 
    } 
} 

I ha Ho visto diverse opzioni per gli evidenziatori (come fragment_size, fragment_offset, phrase_limit), ma nulla è immediatamente evidente come ciò che può essere impostato per migliorare le prestazioni.

Qualche idea su cosa sta succedendo qui? O che tipo di impostazioni posso provare a migliorare le prestazioni?

Nota: uno dei motivi per cui siamo passati dall'evidenziatore di vettore semplice a quello di fatto era dovuto ad alcune query non riuscite con l'evidenziatore semplice.

Edit: Ho aggiunto i passaggi di riproduzione che dimostrano la questione nel seguente link: https://drive.google.com/file/d/0B-IfDOojIDnIQmpkY2RNN2pMREE/edit?usp=sharing

Penso che la chiave è che c'è un campo che contiene un sacco di valori simili (ad esempio, in questo caso, a Caterpillar viene fatto riferimento più volte).

+0

Ho usato with_positions_offsets per circa 20 milioni di record e nessun problema fino ad ora. È persino più veloce di "semplice". Puoi pubblicare il numero medio di record e la lunghezza media di 'contenuto'? Anche la definizione di 'mySearchAnalyzer'. Sarebbe bello se scriveste uno script bash completo che creaindex/inputsomerecords/query e lo mise in evidenza per semplificare l'analisi. –

+0

Questa è una buona idea. Ho aggiunto i passaggi di riproduzione qui: https://drive.google.com/file/d/0B-IfDOojIDnIQmpkY2RNN2pMREE/edit?usp=sharing. Si noti che è sufficiente una piccola quantità di dati per riprodurre il problema. – Eric

+0

Mi spiace tranquillo occupato con il progetto aziendale. Adesso hai solo del tempo libero per tornare. Ho ricreato l'indice e non posso riprodurre il problema, forse b.c i dati non sono sufficienti. Hai mai provato "postings highlighter' (0.90.6+)? Lascia che ci provi b.c i tuoi contenuti sembrano lunghissimi –

risposta

0

Pur non essendo una risposta rigorosa, basata sui commenti di Duc.Duong in cui non era in grado di riprodurre il problema, ho provato a riprodurlo con la versione che stiamo utilizzando (0.90.3) e l'ultimo versopm (1.3. 2). Si scopre che questo non si riproduce più con l'ultima versione - che la ricerca ritorna immediatamente.

Quindi, in conclusione, questo problema non si riproduce con la versione più recente. Non sai dove è stato corretto, ma il problema si verifica in 0.90.3.

Problemi correlati