2013-03-08 13 views
33

Supponiamo di avere un campo stringa specificato come not_analyzed nella mappatura. Se poi aggiungo "store":"yes" alla mappatura, ElasticSearch duplicherà la memoria? La mia comprensione dei campi not_analyzed è che non vengono eseguiti attraverso un Analyzer, indicizzati come, ma un client è in grado di eguagliarlo. Pertanto, se un campo è sia not_analyzed e store:yes, ciò potrebbe causare a ElasticSearch di conservare due copie della stringa.ElasticSearch: impatto dell'impostazione di un campo "not_analyzed" come "store": "yes"?

La mia domanda:

  • Se un campo di stringa viene memorizzato sia come not_analyzed e store:yes, ci sarà lo stoccaggio duplicato della stringa?

Spero che sia abbastanza chiaro. Grazie!

risposta

88

Stai mescolando il concetto di campo indicizzato e campo memorizzato in lucene, la libreria su cui elasticsearch è costruita.

Un campo viene indicizzato quando si passa all'interno dell'indice invertito, la struttura dati che lucene utilizza per fornire le sue capacità di ricerca di testo completo grandi e veloci. Se vuoi cercare su un campo, devi indicizzarlo. Quando indicizzi un campo puoi decidere se lo vuoi indicizzare così com'è, o se vuoi analizzarlo, il che significa decidere un tokenizzatore da applicare ad esso, che genererà un elenco di token (parole) e un elenco di token filtri che possono modificare i token generati (anche aggiungere o eliminare alcuni). Il modo in cui indicizzi un campo influisce su come puoi effettuare una ricerca su di esso. Se indicizzi un campo ma non lo analizzi e il suo testo è composto da più parole, sarai in grado di trovare quel documento solo alla ricerca di quel testo specifico esatto, spazi inclusi.

Un campo viene memorizzato quando si desidera essere in grado di recuperarlo. Diciamo che Lucene fornisce anche una sorta di memoria, che non ha nulla a che fare con l'indice invertito stesso. Quando si esegue una ricerca utilizzando lucene si ottiene un elenco di ID documento corrispondenti. Quindi puoi recuperare del testo dai loro campi memorizzati, che è ciò che stai letteralmente mostrando come risultati di ricerca. Se non archivi un campo non sarai mai in grado di recuperarlo da lucene (questo non è vero per elasticsearch, come spiegherò di seguito).

È possibile avere campi su cui si desidera effettuare la ricerca e non visualizzare mai: indicizzati e non memorizzati (predefinito in lucene).
È possibile avere campi che si desidera cercare e anche recuperare: indicizzati e memorizzati.
È possibile avere campi su cui non si desidera eseguire la ricerca, ma si desidera recuperarli per visualizzarli.

Pertanto le due strutture dati non sono correlate tra loro. Se entrambi indicizzate e memorizzate un campo in lucene, il suo contenuto non sarà presente due volte nella stessa forma. I campi memorizzati vengono memorizzati così come sono, mentre li si invia a lucene, mentre i campi indicizzati potrebbero essere analizzati e faranno parte dell'indice invertito, che è qualcos'altro. I campi memorizzati vengono creati per essere recuperati per un documento specifico (mediante l'id del documento lucene), mentre i campi indicizzati vengono creati per la ricerca, in una struttura che inverte letteralmente il testo avendo come risultato ogni termine come chiave, insieme a un elenco di documenti id che lo contengono (la lista dei messaggi).

Quando si tratta di elasticsearch, le cose cambiano leggermente. Quando non si configura un campo come memorizzato nella mappatura (l'impostazione predefinita è store:no) è possibile recuperarla comunque per impostazione predefinita.Ciò accade perché elasticsearch memorizza sempre in lucene l'intero documento sorgente che gli viene inviato (a meno che non si disabiliti questa funzione) all'interno di uno speciale campo lucene, chiamato _source.

Quando si esegue una ricerca utilizzando elasticsearch si torna indietro per impostazione predefinita sull'intero campo sorgente, ma è anche possibile chiedere campi specifici. Quello che succede in quel caso è che elasticsearch controlla se quei campi specifici sono memorizzati o meno in lucene. Se sono il contenuto verrà recuperato da lucene, altrimenti il ​​campo memorizzato _source verrà recuperato da lucene, analizzato come json (pull parsing) e quei campi specifici verranno estratti. Nel primo caso potrebbe essere un po 'più veloce, ma non necessariamente. Se la tua fonte è veramente grande e vuoi solo caricare un paio di campi, configurarli come memorizzati in lucene probabilmente renderebbe il processo di caricamento più veloce; d'altra parte, se il tuo _source non è così grande e vuoi caricare molti campi, allora è probabilmente meglio caricare solo un campo archiviato (lo _source), che porterebbe a una ricerca su disco singolo, analizzarlo ecc. Nella maggior parte dei casi dei casi utilizzando il campo _source funziona bene.

Per rispondere alla tua domanda: l'indice invertito e l'archivio di lucene sono due cose completamente diverse. Si finisce per avere due copie degli stessi dati in lucene solo se si decide di memorizzare un campo (store:yes nella mappatura), poiché elasticsearch mantiene lo stesso contenuto all'interno di JSON _source, ma questo non ha nulla a che fare con il fatto che stai indicizzando o analizzando il campo.

+1

Grazie. Ho capito la differenza fino ad un certo punto (anche se hai chiarito alcune cose, per fortuna!), La mia domanda era più diretta: se abbiamo intenzione di immagazzinare grandi quantità di brevi (~ stringhe di 80 caratteri) che abbiamo bisogno di recuperare entrambi ed eseguire corrispondenze esatte contro (analizzandole con "not_analyzed"), vi è essenzialmente una duplicazione di dati tra l'indice e ovunque siano memorizzati i campi. Sembra che ci sia, ma come hai spiegato, la loro natura e il loro utilizzo sono molto diversi, quindi non è una vera duplicazione. – aaronlevin

+0

Abbiamo '_source' come' false' per la maggior parte dei nostri campi. – aaronlevin

+0

PS - Grazie per la tua risposta dettagliata. – aaronlevin

Problemi correlati