Quelques notes sur Elasticsearch version 2.4 (en production sur ssodnet.imcce.fr). A vérifier si elles sont toujours d'actualité en version 5.

Généralités

Une recherche de type term n'est pas analysée. Elle est donc sensible à la casse ref.
S'interroger sur le besoin du champ _all lors de la configuration d'un index.
Faire attention au type de recherche utilisé. Selon le type choisi la chaîne sera analysée ou non avant la recherche.
Donner un poids supplémentaire quand la chaîne recherchée correspond exactement à la valeur d'un champ. Par exemple dans le cas des champs name et aliases.
Désactiver le champ _all augmente la flexibilité et la précision du calcul du score ref.
Si des champs n'ont pas à être exposés pour une recherche, on ne les indexe pas (index: no).
Les champs qui n'ont pas besoin d'être analysés (index: not_analyzed) sont traîtés comme des champs keywords ref.
Pour faire une recherche sur plusieurs champs on utilise une recherche de type multi_match ref.
Pour augmenter le score d'une ressource, on utilise le boost au moment de la query et non lors de l'indexation. C'est plus flexible ref. On n'a plus le choix en v5.
Le calcul du score dépend du sharding ref.
On ne peut pas analyser un même champ de façons différentes et l'interroger sous le même nom.
https://www.elastic.co/guide/en/elasticsearch/reference/2.1/search-request-search-type.html
https://www.elastic.co/blog/understanding-query-then-fetch-vs-dfs-query-then-fetch

Si un champ n'a pas de mapping associé alors c'est celui déterminé par ES qui est utilisé (dynamic mapping). Donc si on ne veut pas indexer ou analyser un champ, il faut le dire explicitement.

Fonctionnement des analyzers

Un analyzer est défini par un tokenizer et 0 ou plusieurs token filters. L'objectif du tokenizer est de découper une chaîne en plusieurs tokens. Les token filters traîtent (transforment) chaque token obtenu.

Les analyzers sont utilisés à deux niveaux : lors de l'indexation et lors de la recherche. Ils peuvent être différents mais il faut faire attention à ce qu'ils soient cohérents.

Pour définir un analyzer on doit se poser ce genre de questions :

Possibilité de chercher une chaîne entière ?
Comment découper la chaîne en tokens (sur quels caractères) ?
Supprimer les caractères non significatifs (parenthèses pas exemple) ?
Recherche sensible à la casse ?
Gestion de l'élision ?
Recherche sensible aux caractères accentués ?

Test des fonctionnalités

Pour avoir des sorties cURL plus lisibles on peut utiliser l'outil python mjson ou ajouter le paramètre pretty=true à l'URI.

curl curl_parameters | python -mjson.tool

Vérifier la configuration du mapping

Cette étape est nécesaire pour s'assurer que les champs ont bien le mapping défini.

http://ssodnet.imcce.fr:9200/ssodnet/_mapping

API _analyze

Tester un analyzer

curl 'http://ssodnet.imcce.fr:9200/ssodnet/_analyze?analyzer={ANALYZER}&pretty=true' -d "string"

Exemple :

curl 'http://ssodnet.imcce.fr:9200/ssodnet/_analyze?analyzer=search_is_analyzer&pretty=true' -d "P/2000 Haléo"

Tester un tokenizer

curl 'http://ssodnet.imcce.fr:9200/ssodnet/_analyze?tokenizer={TOKENIZER}&pretty=true' -d "string"

Exemple :

curl 'http://ssodnet.imcce.fr:9200/ssodnet/_analyze?tokenizer=standard&pretty=true' -d "P/2000 Haléo"

Tester les token filters

curl 'http://ssodnet.imcce.fr:9200/ssodnet/_analyze?tokenizer={TOKENIZER}&filters={TF1},{TF2}&pretty=true' -d "string"

Exemple :

curl 'http://ssodnet.imcce.fr:9200/ssodnet/_analyze?tokenizer=standard&filters=lowercase,asciifolding&pretty=true' -d "P/2000 Haléo"

Tester comment un champ est analysé

Cela permet de vérifier que le configuration du mapping est correcte.

curl 'http://ssodnet.imcce.fr:9200/ssodnet/_analyze?field={FIELD}&pretty=true' -d "string"

Exemples :

curl 'http://ssodnet.imcce.fr:9200/ssodnet/_analyze?field=name.raw&pretty=true' -d "P/2000 Haléo"
curl 'http://ssodnet.imcce.fr:9200/ssodnet/_analyze?field=name.sayt&pretty=true' -d "P/2000 Haléo"

Si le champ est inconnu c'est l'analyzer standard qui sera utilisé. Pour les champs analysés de plusieurs façons différentes il faut bien indiquer le suffixe sinon l'analyzer standard sera utilisé.

API _validate

Permet de voir comment la recherche est effectuée.

curl 'http://ssodnet.imcce.fr:9200/ssodnet/sso/_validate/query?rewrite=true&pretty=true' -d '
{"query": {
   "multi_match": {
      "query": "1950 TT2",
      "type": "best_fields",
      "fields": ["name.raw^2", "name", "aliases.raw^2", "aliases"],
      "operator": "and"
   }
}}'

curl 'http://ssodnet.imcce.fr:9200/ssodnet/sso/_validate/query?rewrite=true&pretty=true' -d '
{"query": {
   "query_string": {
      "query": "1950 TT2",
      "fields" : ["name.raw", "name", "aliases.raw", "aliases"]
   }
}}'

API _search

Highlight

curl 'http://ssodnet.imcce.fr:9200/ssodnet/sso/_search?pretty=true' -d '
{"query": {
   "multi_match": {
      "query": "2001 L",
      "fields": ["name.sayt"]
   }},
   "highlight": {
      "fields": {
         "name.sayt": {}
      }
}}'

curl 'http://ssodnet.imcce.fr:9200/ssodnet/sso/_search?pretty=true' -d '
{"query": {
   "multi_match": {
      "query": "C/2003",
      "fields": ["name.raw^2", "name.sayt", "aliases.raw^2", "aliases.sayt"]
   }},
   "highlight": {
      "fields": {
         "name.raw": {},
          "name.sayt": {},
          "aliases.raw": {},
          "aliases.sayt": {}
      }
}}'

Quand on highlight sur un champ multi-valué le highlight est sur l'intégralité de la chaîne (semble être le cas tout le temps). Dans l'exemple précédent les champs aliases.* sont multi-valués alors que name.* non.

Recherche

Recherche exacte - query

Dans ce cas on recherche exactement un ou plusieurs tokens. C'est à dire que tous les tokens doivent apparaître dans les champs demandés (ici toutes les déclinaisons de name et aliases avec un boost si la chaîne recherchée a la même valeur que celle du champ). La recherche présentée dans l'exemple n'est pas sensible à la casse (cf. mapping ssodnet).

curl 'http://ssodnet.imcce.fr:9200/ssodnet/sso/_search?pretty=true' -d '
{"query": {
   "multi_match": {
      "query": "1950 TT2",
      "type": "best_fields",
      "fields": ["name.raw^2", "name", "aliases.raw^2", "aliases"],
      "operator": "and"
   }
}}'

La recherche de type multi_match est analysée avant d'être executée :

name.raw et aliases.raw donnent un unique token "1950 tt2"
name et aliases donnent deux tokens "1950" et "tt2"

On peut aussi ajouter un filtre pour affiner cette recherche (ici sur le champ type). Ce filtre est effectué au moyen d'une recherche de type term. La chaîne n'est donc pas analysée avant d'être exécutée. Elle est donc sensible à la casse.

curl 'http://ssodnet.imcce.fr:9200/ssodnet/sso/_search?pretty=true' -d '
{"query": {
   "bool": {
      "must": [
         {"multi_match": {
            "query": "io",
            "fields": ["name.raw^2", "name", "aliases.raw^2", "aliases"],
            "operator": "and"
         }}
      ],
      "filter": [
         {"term": {"type": "Asteroid"}}
      ]
   }
}}'

Pour filtrer les données selon le type (dans cet exemple), on se place dans un context filter car on ne veut pas obtenir de résultats qui ne correspondent pas au type demandé. Si on avait utilisé une clause match, la requête aurait aussi retournée des ressources du mauvais type mais avec un score faible (donc en fin de liste).

Recherche avancée - query_string

Dans ce cas on peut exprimer sa propre requête et non une simple liste de tokens. La syntaxe est documentée ici. On peut aussi utiliser une version simplifiée qui n'est pas sensible aux erreurs dans la saisie de la requête.

Si _all n'est pas défini dans l'index, on doit préciser les champs utilisés en l'absence de préfix (attribut fields).
Si on recherche une phrase (l'expression recherchée contient des espaces) il faut utiliser des doubles quotes.
OR est l'opérateur par défaut. On doit donc indiquer AND entre les clauses si besoin.
Certains caractères font partie de la grammaire Lucene. L'utilisateur doit les échapper s'il veut les utiliser dans les tokens à chercher.

curl 'http://ssodnet.imcce.fr:9200/ssodnet/sso/_search?pretty=true' -d '
{"query": {
   "query_string": {
      "query": "1950 tt2",
      "fields": ["name.raw", "name", "aliases.raw", "aliases"]
   }
}}'

curl 'http://ssodnet.imcce.fr:9200/ssodnet/sso/_search?pretty=true' -d '
{"query": {
   "query_string": {
      "query": "\"1950 tt2\"",
      "fields": ["name.raw", "name", "aliases.raw", "aliases"]
   }
}}'

L'utilisation de l'API _validate montre pourquoi ces deux exemples ne retournent pas le même résultat.

curl 'http://ssodnet.imcce.fr:9200/ssodnet/sso/_validate/query?rewrite=true&pretty=true' -d '
{"query": {
   "query_string": {
      "query": "1950 tt2",
      "fields": ["name.raw", "name", "aliases.raw", "aliases"]
   }
}}'

curl 'http://ssodnet.imcce.fr:9200/ssodnet/sso/_validate/query?rewrite=true&pretty=true' -d '
{"query": {
   "query_string": {
      "query": "\"1950 tt2\"",
      "fields": ["name.raw", "name", "aliases.raw", "aliases"]
   }
}}'

explanation : +(name.raw:1950 tt2 | name:\"1950 tt2\" | aliases.raw:1950 tt2 | aliases:\"1950 tt2\")

dfs_query_then_fetch

Si le classement des résultats retournés semble étrange (c-à-d que le calcul du score ne correspond pas à ce que la logique voudrait), c'est peut être dû au sharding.

Cf. https://www.elastic.co/blog/understanding-query-then-fetch-vs-dfs-query-then-fetch

Application à SsODNet/Quaero

Les champs présents dans les ressources sont principalement de type string:

name, system, parent, type : (string)
aliases, class : (array(string)) => champs multi-valués dans Elasticsearch

Les différents désignations pour un objet se trouvent dans les champs name et aliases.

Pas de recherche de type term car elle est sensible à la casse.
Pas de _all. Les champs par défaut sont définis dans la query.
On choisi un type de recherche où la chaîne est analysée avant la recherche.
On donne un poids supplémentaire à une ressource quand la chaîne recherchée correspond exactement à la valeur d'un champ.
On utilise une recherche de type multi_match car on recherche sur plusieurs champs.
On analyse certains champs de plusieurs façons différentes
On défini le mapping pour tous les champs pour éviter les mauvaises surprises

On propose 3 façons de faire des recherches dans SsODNet :

recherche simple (endpoint /sso)
recherche avancée (endpoint /sso/search)
autocomplétion (endpoint /sso/instant-search)

Cas d'utilisation :

trouver P/Halley via (P/Halley, Halley ou halley)
trouver P/Shoemaker-Levy via (P/Shoemaker-Levy, Shoemaker ou Levy)
trouver S/2011 (2001 XP254) via (XP254)
rechercher CoRot-1 doit uniquement retourner CoRot-1 (pas de CoRot*)
trouver uniquement 2013 AB via (2013 AB)
trouver à partir des premiers caractères d'une désignation ou d'un token de cette désignation
trouver les corps par leur numéro (1 via 1)

Analyzers

Pour répondre aux cas d'utilisation du service, on défini plusieurs analyzers :

prendre en compte les espaces (chaîne entière)
découpage en tokens
insensible à la casse et aux accents
ne pas découper les tokens alpha-numérique
conserver les tokens de n'importe quelle longueur
découper les tokens en suite de caractères (autocomplétion)

Cf. définition du service.

Recherche

/sso

Dans ce cas d'utilisation l'utilisateur entre une liste de tokens et s'attend à obtenir comme résultat les sso où tous les tokens sont trouvés dans les champs name ou aliases.

Comme le champ aliases est multi-valué on peut obtenir des sso dont un des alias contient un token et un autre alias contient un autre token. Par exemple une recherche de 2000 JW8 retourne un sso avec un alias 2000 AB174 et un alias 1997 JW8.

Comme on recherche dans plusieurs champs, on utilise une recherche de type multi_match et on attribue un poids supplémentaire.

Dans cette recherche le même analyzer est utilisé pour l'indexation et la recherche.

Cf Recherche exacte - query

/sso/search

Dans ce cas d'utilisation une recherche est possible sur aucun ou des champs donnés. Les contraintes sont alors exprimées sous forme de clé:valeur. Si la clé n'est pas indiquée alors les tokens sont recherchés dans les attributs name et aliases (car le _all est désactivé).

Cas d'une recherche sur corot-1 :

q=corot-1 retourne corot* et 1
q=name:corot-1
q="corot-1" et q=name:"corot-1" retourne uniquement CoRoT-1

Le résultat obtenu pour une recherche sans préciser d'attribut est dû au fait que les champs utilisés dans ce cas sont name, aliases, name.raw et aliases.raw. Or l'analyzer utilisé pour name indexe ce champ comme (corot-1, corot, 1) et c'est le même analyzer utilisé pour la recherche.

Cf. Recherche avancée - query_string

TBD utiliser un analyzer qui ne fait rien au moment de la query pour chercher exactement le token entré ?

/sso/instant-search

Dans ce cas on veut pouvoir faire une saisie avec autocomplétion à partir du début de la chaîne ou d'un de ses tokens.

L'analyzer utilisé lors de le recherche est différent de celui de utilisé lors de l'indexation.

L'analyzer à l'indexation doit :

garder la chaîne entière ;
découper en tokens ;
appliquer un ngram sur les tokens et la chaîne entière ;
insensible à la case et aux accents ;

L'analyzer à la recherche doit uniquement :

insensible à la case et aux accents ;

Deux approches sont possibles : match_phrase_prefix ou edgengram. Comme c'est plus performant de découper les tokens lors de l'indexation on utilise un token filter de type edgeNGram (cf. 1 et 2).

Choix de la taille du edgeNGram :

maxgram pas trop court pour contenir l'intégralité d'un nom ;
mingram de 2 permet de faire de l'autocomplétion sur 1 caractère car le nom entier est aussi indexé. Par exemple Cérès (alias 1).

Notes sur Elasticsearch 2.4

Jonathan Normand, jonathan.normand@obspm.fr

Last updated: Friday May 12, 2017

Généralités

Fonctionnement des analyzers

Test des fonctionnalités

Vérifier la configuration du mapping

API _analyze

Tester un analyzer

Tester un tokenizer

Tester les token filters

Tester comment un champ est analysé

API _validate

API _search

Highlight

Recherche

Recherche exacte - query

Recherche avancée - query_string

Application à SsODNet/Quaero

Analyzers

Recherche

/sso

/sso/search

/sso/instant-search