Elastic search- search_analyzer vs index_analyzer




search elasticsearch match (2)

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

Je n'ai pas compris la partie concernant les différents analyseurs de recherche et d'index. Le deuxième exemple de mappage personnalisé va comme ceci:
-> 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.


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

Il est parfois judicieux d'utiliser un analyseur différent à l'index et à la recherche. Par exemple, au moment de l'index, nous pouvons vouloir indexer des synonymes, par exemple pour chaque occurrence de rapide, nous indexons aussi rapidement, rapidement et rapidement. 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 seul mot que l'utilisateur a entré, que ce soit rapide, rapide, rapide ou rapide.

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

En prenant en compte ces paramètres supplémentaires, la séquence complète au moment de l'index ressemble à ceci:

  • l'index_analyzer défini dans le mappage de champ, sinon
  • l'analyseur défini dans la cartographie du champ, sinon
  • l'analyseur défini dans le champ _analyzer du document, sinon
  • l'index_analyzer par défaut pour le type, 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 de l'index, qui par défaut
  • l'analyseur nommé par défaut dans les paramètres d'index, qui par défaut
  • l'analyseur nommé default_index au niveau du nœud, qui par défaut
  • l'analyseur nommé par défaut au niveau du nœud, qui est par défaut
  • 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 du champ, sinon
  • l'analyseur défini dans la cartographie du champ, 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 par défaut
  • l'analyseur nommé par défaut dans les paramètres d'index, qui par défaut
  • l'analyseur nommé default_search au niveau du noeud, par défaut
  • l'analyseur nommé par défaut au niveau du nœud, qui est par défaut
  • l'analyseur standard

Vous avez généralement une chaîne d'analyse similaire à la fois à l'heure de l'index et à l'heure 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 de ngrams est très bien adapté, car c'est l'une des principales raisons pour lesquelles vous utiliseriez des analyseurs différents à l'heure de l'index et de la requête.

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

"ela", "elas", "elast", "elasti", "élastique", "élastique", "elasticse", "elasticsea", "elasticsear", "eleasticsearc" et "elasticsearch"

Interrogeons maintenant le champ créé. Si nous demandons le terme "élastique", il y a correspondance et nous obtenons le résultat attendu. Nous avons essentiellement fait de ce que nous appelions ci-dessus une correspondance partielle, une correspondance exacte, compte tenu de ce que nous avons indexé. Il n'est pas nécessaire d'appliquer ngrams à la requête aussi. Si nous l'avions fait, nous demanderions tous les termes suivants:

"ela", "elas", "elast", "elasti" et "élastique"

Cela rendrait la requête beaucoup plus complexe et conduirait à 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", "s'écouler", "écoulé"

Si vous recherchez "élastique" et faites ngrams à la requête, le terme "ela" correspondrait aussi à ce second document, donc vous le récupéreriez avec le premier document, même si aucun terme ne contient le terme "élastique" nous recherchons.

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







analyzer