2016-01-02 10 views
6

Lottando per far corrispondere iPhone durante la ricerca di iphone in Elasticsearch.Escludi dal tokenizzatore CamelCase in Elasticsearch

Poiché ho in gioco qualche codice sorgente, ho sicuramente bisogno di CamelCase tokenizer, ma sembra che rompa l'iPhone in due termini, quindi non è possibile trovare l'iphone.

Qualcuno sa come aggiungere eccezioni alle parole di camelCase in token (cammello + caso)?

AGGIORNAMENTO: per rendere più chiaro, voglio che NullPointerException venga tokenizzato come [null, pointer, exception], ma non voglio che iPhone diventi [i, phone].

Qualsiasi altra soluzione?

UPDATE 2: @ risposta di ChintanShah suggerisce un approccio diverso che ci dà ancora più - NullPointerException verrà token come [nullo, puntatore, eccezione, nullpointer, pointerexception, NullPointerException], che è sicuramente molto più utile dal punto di vista di quello che cerca. E l'indicizzazione è anche più veloce! Il prezzo da pagare è la dimensione dell'indice, ma è una soluzione superiore.

+0

cosa non usi il filtro minuscolo? Minuscole tutte le parole – ChintanShah25

+0

@ ChintanShah25 In che modo questo aiuta a correggere il tokenizzatore? (e btw - utilizzo il filtro minuscolo) I tokenizer – tishma

+0

sono diversi dai filtri. iPhone verrà indicizzato come iphone con filtro minuscolo. Sarebbe utile se tu pubblicassi il tuo attuale anlayzer e mappassi – ChintanShah25

risposta

6

È possibile raggiungere i requisiti con word_delimiter token filter. Questa è la mia messa a punto

{ 
    "settings": { 
    "analysis": { 
     "analyzer": { 
     "camel_analyzer": { 
      "tokenizer": "whitespace", 
      "filter": [ 
      "camel_filter", 
      "lowercase", 
      "asciifolding" 
      ] 
     } 
     }, 
     "filter": { 
     "camel_filter": { 
      "type": "word_delimiter", 
      "generate_number_parts": false, 
      "stem_english_possessive": false, 
      "split_on_numerics": false, 
      "protected_words": [ 
      "iPhone", 
      "WiFi" 
      ] 
     } 
     } 
    } 
    }, 
    "mappings": { 
    } 
} 

Ciò dividere le parole su caso le modifiche così NullPointerException saranno token come nulla, puntatore e eccezione ma iPhone e WiFi rimarranno come è così come sono protetti . word_delimiter ha molte opzioni per la flessibilità. Puoi anche preserve_original che ti aiuterà molto.

GET logs_index/_analyze?text=iPhone&analyzer=camel_analyzer 

Risultato

{ 
    "tokens": [ 
     { 
     "token": "iphone", 
     "start_offset": 0, 
     "end_offset": 6, 
     "type": "word", 
     "position": 1 
     } 
    ] 
} 

Ora con

GET logs_index/_analyze?text=NullPointerException&analyzer=camel_analyzer 

Risultato

{ 
    "tokens": [ 
     { 
     "token": "null", 
     "start_offset": 0, 
     "end_offset": 4, 
     "type": "word", 
     "position": 1 
     }, 
     { 
     "token": "pointer", 
     "start_offset": 4, 
     "end_offset": 11, 
     "type": "word", 
     "position": 2 
     }, 
     { 
     "token": "exception", 
     "start_offset": 11, 
     "end_offset": 20, 
     "type": "word", 
     "position": 3 
     } 
    ] 
} 

Un altro approccio è quello di analizzare il vostro campo due volte con differenti analizzatori ma sento word_delimiter farà il trucco.

Questo aiuto?

+0

Aiuta molto! Penso che preserve_original e persino catenate_all sia un must, dato che è una soluzione completa. Chi non si aspetterebbe di trovare NullPointerException quando cerca NullPointerException invece di cercarne solo alcune parti! – tishma

+0

Come ho già detto Ha molte opzioni, è possibile modificarlo in base alle varie esigenze. – ChintanShah25

+0

non c'è bisogno di essere invadenti;) Sto pensando di cambiare la domanda un po ', perché word_delimiter è in realtà una soluzione per un caso più generale. A proposito, il tokenizzatore di lettere funzionava molto meglio degli spazi bianchi per me. Ed è tutto il 15-40% più veloce rispetto all'utilizzo del modello suggerito nei documenti per il caso cammello! – tishma