2013-05-13 13 views
24

La differenza tra i due, che detengono tutti i campi, mi sfugge.qual è la differenza tra _source e _all in Elasticsearch

Se il mio documento ha:

{"mydoc": 
    {"properties": 
     {"name":{"type":"string","store":"true"}}, 
     {"number":{"type":"long","store":"false"}}, 
     {"title":{"type":"string","include_in_all":"false","store":"true"}} 

    } 
} 

capisco che sorgente_ è un campo che ha tutti i campi. Ma anche _all? Significa che i "nomi" vengono salvati più volte (due volte? In _src e in _all), aumentando lo spazio su disco occupato dal documento?

Il "nome" è memorizzato una volta per il campo, una volta per _source e una volta per _all? che dire di "numero", è memorizzato in tutti, anche se non in _source?

Quando dovrei usare _source nella mia query e quando _all?

Qual è il caso in cui è possibile disattivare "_all" e quale funzionalità sarebbe quindi negata?

risposta

43

È praticamente la stessa differenza tra i campi indicizzati e i campi memorizzati in lucene.

Si utilizzano campi indicizzati quando si desidera eseguire la ricerca su di essi, mentre si memorizzano i campi che si desidera restituire come risultati di ricerca.

Il campo _source è pensato per memorizzare l'intero documento di origine inviato originariamente a elasticsearch. È usato come risultato della ricerca, da recuperare. Non puoi cercare su di esso. In realtà è un campo memorizzato in lucene e non indicizzato.

Il campo _all ha lo scopo di indicizzare tutto il contenuto proveniente da tutti i campi di cui sono composti i documenti. Puoi cercare su di esso ma non restituirlo mai, poiché è indicizzato ma non memorizzato in lucene.

Non c'è ridondanza, i due campi sono pensati per un altro caso e memorizzati in posti diversi, all'interno dell'indice di lucene. Il campo _all diventa parte di ciò che chiamiamo indice invertito, utilizza il testo dell'indice ed è in grado di eseguire la ricerca full-text contro di esso, mentre il campo _source viene semplicemente memorizzato come parte dei documenti lucene.

Non si utilizzerà mai il campo _source nelle query, solo quando si ottengono risultati poiché è ciò che elasticsearch restituisce per impostazione predefinita. Ci sono alcune caratteristiche che dipendono dal campo _source, che si perde se lo si disabilita. Uno di questi è lo update API. Inoltre, se lo disabiliti devi ricordarti di configurare come store:yes nella tua mappatura tutti i campi che vuoi restituire come risultati di ricerca. Direi piuttosto di non disabilitarlo a meno che non ti dia fastidio, dal momento che è molto utile in molti casi. Un altro usecase comune sarebbe quando hai bisogno di reindicizzare i tuoi dati; puoi semplicemente recuperare tutti i tuoi documenti da elasticsearch e inviarli nuovamente a un altro indice.

D'altra parte, il campo _all è solo un campo di acquisizione predefinito, che è possibile utilizzare quando si desidera eseguire la ricerca su tutti i campi disponibili e non si desidera specificarli tutti nelle query. È comodo, ma non lo farei troppo sulla produzione, dove è meglio eseguire query più complesse su campi diversi, con pesi diversi ciascuna. Si potrebbe desiderare di disabilitarlo se non lo si utilizza, questo avrà un impatto minore rispetto a disabilitare il _source a mio parere.

+0

Grazie! Se imposto un campo su "index": "no", appare ancora in "_all", giusto? Quindi, se non ho intenzione di fare una ricerca di testo completo su più di un campo specifico alla volta, trasformando "include_in_all" in "falso" su tutti i miei campi si risparmia spazio, giusto? – eran

+1

Nel frattempo ho aggiunto altri pensieri alla mia risposta. Il campo '_all' è impostato di default come' "index": yes' e non si riferisce alla mappatura degli altri campi se non quando si utilizza l'opzione 'include_in_all'. Se non usi il campo '_all', lo disabilito completamente invece di impostare tutti i campi su' "include_in_all": false'. – javanna

+0

Grazie, disabilitare il campo '_all' per risparmiare spazio su disco? (sembra quasi che raddoppi lo spazio necessario, intuitivamente) – eran

Problemi correlati