web-dev-qa-db-fra.com

Recherche élastique - search_analyzer vs index_analyzer

Je regardais http://euphonious-intuition.com/2012/08/more-complicated-mapping-in-elasticsearch/ qui explique les analyseurs ElasticSearch.

Je ne comprenais pas la partie d'avoir différents analyseurs de recherche et d'index. Le deuxième exemple de mappage personnalisé se présente comme suit:
-> l'analyseur d'index est un edgeNgram
-> l'analyseur de recherche est:

"full_name":{
    "filter":[
        "standard",
        "lowercase",
        "asciifolding"
    ],
    "type":"custom",
    "tokenizer":"standard"
}

si nous voulions que la requête "Race" ne renvoie pas de résultats comme * ra * pport et * rac * ial en raison de edgeNgram, pourquoi l'indexer avec edgeNgram en premier lieu?

Veuillez expliquer avec un exemple où différents analyseurs sont utiles.

searchelasticsearchanalyzer
37
Pavan K Mutt

Vous disposez généralement d'une chaîne d'analyse similaire au moment de l'index et au moment de la requête. Similaire ne signifie pas exactement la même chose, mais généralement la façon dont vous indexez les documents reflète la façon dont vous les interrogez.

L'exemple ngrams est cependant très bien adapté, car c'est l'une des principales raisons pour lesquelles vous utiliseriez différents analyseurs au moment de l'indexation et de la requête.

Pour les correspondances partielles, vous indexez avec Edge ngrams, de sorte que "elasticsearch" devienne (avec mingram 3 et maxgram 20):

"ela", "elas", "elast", "elasti", "elastic", "elastics", "elasticse", "elasticsea", "elasticsear", "eleasticsearc" et "elasticsearch"

Interrogons maintenant le champ créé. Si nous recherchons le terme "élastique", il y a une correspondance et nous obtenons le résultat attendu. Nous avons essentiellement fait de ce que nous avons appelé ci-dessus une correspondance partielle une correspondance exacte, compte tenu de ce que nous avons indexé. Il n'est pas nécessaire non plus d'appliquer des ngrammes à la requête. Si nous le faisions, nous demanderions tous les termes suivants:

"ela", "elas", "elast", "elasti" et "elastic"

Cela rendrait la requête beaucoup plus complexe et conduirait également à des résultats étranges. Disons que vous indexez le terme "écoulé" dans un autre document, même champ. Vous auriez les ngrams suivants:

"ela", "elap", "elaps", "elapse", "elapsed"

Si vous recherchez "élastique" et créez des ngrammes à la requête, le terme "ela" correspondrait également à ce deuxième document, ainsi vous le retrouveriez avec le premier document, même si aucun terme ne contient le terme "élastique" que vous nous recherchons.

Je vous suggère de jeter un oeil à la analyse de l'api pour jouer avec différents analyseurs et leurs différents résultats.

80
javanna

Pour référencer la documentation officielle sur les analyseurs d'index vs de recherche :

Parfois, il est judicieux d'utiliser un analyseur différent au moment de l'indexation et de la recherche. Par exemple, au moment de l'indexation, nous pouvons vouloir indexer des synonymes, par exemple pour chaque occurrence de quick, nous indexons également fast, rapid et speedy. Mais au moment de la recherche, nous n'avons pas besoin de rechercher tous ces synonymes. Au lieu de cela, nous pouvons simplement rechercher le mot unique que l'utilisateur a entré, que ce soit rapide, rapide, rapide ou rapide.

Pour permettre cette distinction, Elasticsearch prend également en charge les paramètres index_analyzer et search_analyzer, ainsi que des analyseurs nommés default_index et default_search.

Compte tenu de ces paramètres supplémentaires, la séquence complète au moment de l'index ressemble vraiment à ceci:

  • l'index_analyzer défini dans le mappage de champ, sinon
  • l'analyseur défini dans la cartographie de terrain, sinon
  • l'analyseur défini dans le champ _analyzer du document, sinon
  • l'index_analyzer par défaut pour le type, qui est par défaut
  • l'analyseur par défaut pour le type, qui est par défaut
  • l'analyseur nommé default_index dans les paramètres d'index, qui est par défaut
  • l'analyseur nommé par défaut dans les paramètres d'index, qui est par défaut
  • l'analyseur nommé default_index au niveau du nœud, qui est par défaut
  • l'analyseur nommé par défaut au niveau du nœud, qui par défaut est
  • l'analyseur standard

Et au moment de la recherche:

  • l'analyseur défini dans la requête elle-même, sinon
  • le search_analyzer défini dans le mappage de champ, sinon
  • l'analyseur défini dans la cartographie de terrain, sinon
  • le search_analyzer par défaut pour le type, qui est par défaut
  • l'analyseur par défaut pour le type, qui est par défaut
  • l'analyseur nommé default_search dans les paramètres d'index, qui est par défaut
  • l'analyseur nommé par défaut dans les paramètres d'index, qui est par défaut
  • l'analyseur nommé default_search au niveau du nœud, qui par défaut est
  • l'analyseur nommé par défaut au niveau du nœud, qui par défaut est
  • l'analyseur standard
8
Asimov4