Guide de saisie semi-automatique Elasticsearch

Équipe Opster

Dernière mise à jour : Mars 2021

Équipe Opster

Mars 2021

En plus de lire ce guide, nous vous recommandons d’exécuter le bilan de santé Elasticsearch. Il détectera les problèmes et améliorera vos performances Elasticsearch en analysant la taille de vos fragments, vos outils de thread, votre mémoire, vos instantanés, vos filigranes de disque, etc.Le Check-Up Elasticsearch est gratuit et ne nécessite aucune installation.

En plus de lire ce guide, vous devez exécuter l’analyseur de journal de recherche d’Opster si vous souhaitez améliorer vos performances de recherche dans Elasticsearch.

Avec l’analyseur d’Opster, vous pouvez facilement localiser les recherches lentes et comprendre ce qui les a amenées à ajouter une charge supplémentaire à votre système. Vous recevrez des recommandations personnalisées pour réduire la latence de recherche et améliorer vos performances de recherche. L’outil est gratuit et ne prend que 2 minutes à exécuter.

Contexte

Dans cet article, nous expliquerons comment éviter les erreurs de performances critiques, pourquoi la solution par défaut d’Elasticsearch ne la coupe pas, et les considérations d’implémentation importantes.
Tous les sites Web modernes ont des fonctionnalités de saisie semi-automatique (recherche au fur et à mesure que vous tapez) dans leur barre de recherche pour améliorer l’expérience utilisateur (personne ne veut taper des termes de recherche entiers…). Il est impératif que la saisie semi-automatique soit plus rapide que la recherche standard, car le but de la saisie semi-automatique est de commencer à afficher les résultats pendant que l’utilisateur tape. Si la latence est élevée, cela conduira à une expérience utilisateur inférieure.

Voici un exemple de recherche de saisie semi-automatique sur le célèbre site de questions-réponses, Quora. C’est un bon exemple de saisie semi-automatique: lors de la recherche d’elasticsearch auto, les messages suivants commencent à s’afficher dans leur barre de recherche.

 Cette image a un attribut alt vide; son nom de fichier est GtQyiRxpwyXg_NmYFLO5mSlG5Zwa-k6a-s2AIi-uP3EsEP8dRql8eR0CrfGZlN_PIcUMU9K-GDZ2WfEASrxgxGSXiE37pzwNNffIcjq-xlBA982DZe8TQJFzYaLl8WojdrdlVNjQ

Notez que dans les résultats de recherche, il y a des questions relatives aux fonctionnalités de mise à l’échelle automatique, de balise automatique et de saisie semi-automatique d’Elasticsearch. Les utilisateurs peuvent en outre taper quelques caractères supplémentaires pour affiner les résultats de la recherche.

Diverses approches pour la saisie semi-automatique dans Elasticsearch/search lorsque vous tapez

Il existe plusieurs façons d’implémenter la fonctionnalité de saisie semi-automatique qui se répartissent généralement en quatre catégories principales:

  1. Temps d’index
  2. Temps de requête
  3. Suggestion d’achèvement
  4. Base de données de recherche en tant que type

1. Temps d’index

Parfois, les exigences ne sont que l’achèvement du préfixe ou l’achèvement de l’infixe dans la saisie semi-automatique. Il n’est pas rare de voir une implémentation de saisie semi-automatique à l’aide des analyseurs personnalisés, ce qui implique d’indexer les jetons de manière à ce qu’ils correspondent au terme de recherche de l’utilisateur.
Si nous continuons avec notre exemple, nous examinons des documents qui se composent de “saisie semi-automatique elasticsearch”, “balise automatique elasticsearch”, “mise à l’échelle automatique elasticsearch” et “elasticsearch automatiquement”. L’analyseur par défaut ne générera aucun jeton partiel pour “saisie semi-automatique”, “mise à l’échelle automatique” et “automatiquement”, et la recherche “automatique” ne donnerait aucun résultat.
Pour résoudre le problème ci-dessus, edge ngram ou n-gram tokenizer sont utilisés pour indexer les jetons dans Elasticsearch, comme expliqué dans le document ES officiel et l’analyseur de temps de recherche pour obtenir les résultats de saisie semi-automatique.
L’approche ci-dessus utilise des requêtes de correspondance, qui sont rapides car elles utilisent une comparaison de chaînes (qui utilise un code de hachage), et il y a relativement moins de jetons exacts dans l’index.

2. La saisie semi-automatique du temps de requête

peut être obtenue en changeant les requêtes de correspondance en requêtes de préfixe. Alors que les requêtes de correspondance fonctionnent sur les jetons (indexés) sur les jetons (jetons de requête de recherche), les requêtes de préfixe (comme leur nom l’indique) correspondent à tous les jetons commençant par les jetons de recherche, d’où le nombre de documents (résultats) appariés est élevé.

Comme expliqué, la requête de préfixe n’est pas une correspondance de jeton exacte, elle est plutôt basée sur des correspondances de caractères dans la chaîne, ce qui est très coûteux et récupère beaucoup de documents. Elasticsearch utilise en interne une structure de données de type arbre B+ pour stocker ses jetons. Il est utile de comprendre les éléments internes de la structure de données utilisée par les indices inversés et l’impact des différents types de requêtes sur les performances et les résultats.

3. Suggestion d’achèvement

Ceci est utile si vous fournissez des suggestions de termes de recherche comme sur les sites de commerce électronique et de recherche d’hôtels. La barre de recherche propose des suggestions de requête, par opposition aux suggestions apparaissant dans les résultats de recherche réels, et après avoir sélectionné l’une des suggestions fournies par completion suggester, elle fournit les résultats de la recherche.

Comme mentionné sur le document ES officiel, il est toujours en développement et ne récupère pas les résultats de recherche en fonction des termes de recherche comme expliqué dans notre exemple.

En interne, cela fonctionne en indexant les jetons que les utilisateurs veulent suggérer et non en fonction de documents existants.

Exemples de codes

1. Temps d’index

Définition d’index:

{ "settings": { "analysis": { "filter": { "autocomplete_filter": { "type": "edge_ngram", "min_gram": 1, "max_gram": 10 } }, "analyzer": { "autocomplete": { "type": "custom", "tokenizer": "standard", "filter": } } } }, "mappings": { "properties": { "title": { "type": "text", "analyzer": "autocomplete", "search_analyzer": "standard" :-> note search_analyzer } } }}

Requête de recherche:

{ "query": { "match": { "movie_name": { "query": "avengers inf" } } }}

2. Temps de requête

Définition de l’index:

{ "mappings": { "properties": { "movie_name": { "type": "text" } } }}

Requête de recherche:

{ "query": { "bool": { "should": } }}

4. Recherche en tapant

Il s’agit d’un type de données récemment publié (publié dans la version 7.2) destiné à faciliter les requêtes de saisie semi-automatique sans connaissance préalable de la configuration de l’analyseur personnalisé. Elasticsearch stocke en interne les différents jetons (edge n-gram, shingles) du même texte, et peut donc être utilisé à la fois pour la complétion des préfixes et des infixes. Cela peut être pratique s’il n’est pas familier avec les fonctionnalités avancées d’Elasticsearch, ce qui est le cas des trois autres approches. Peu de configuration est nécessaire pour le faire fonctionner avec des cas d’utilisation simples, et des exemples de code et plus de détails sont disponibles sur les documents ES officiels.

Prise en compte des performances

Presque toutes les approches ci-dessus fonctionnent correctement sur des ensembles de données plus petits avec des charges de recherche plus légères, mais lorsque vous avez un index massif obtenant un nombre élevé de requêtes de suggestion automatique, le SLA et les performances des requêtes ci-dessus sont essentielles. Les points suivants devraient vous aider à choisir l’approche la mieux adaptée à vos besoins:

  • Les jetons Ngram ou edge Ngram augmentent considérablement la taille de l’indice, fournissant les limites de gramme min et max en fonction de l’application et de la capacité. La planification permettrait d’éviter d’importants problèmes de production.
  • Autoriser des requêtes de préfixe de caractères vides ou peu nombreuses peut faire apparaître tous les documents d’un index et a le potentiel de faire tomber un cluster entier. C’est toujours une meilleure idée de faire une requête de préfixe uniquement sur le nième terme (sur quelques champs) et de limiter les caractères minimum dans les requêtes de préfixe.
  • ES fourni le type de données “rechercher au fur et à mesure que vous tapez” tokenise le texte d’entrée dans différents formats. Comme il s’agit d’une solution fournie par ES qui ne peut pas traiter tous les cas d’utilisation, il est toujours préférable de vérifier tous les cas d’angle requis pour votre cas d’utilisation professionnel. De plus, comme mentionné précédemment, il permet de segmenter les champs dans plusieurs formats, ce qui peut augmenter la taille du magasin d’index Elasticsearch.
  • L’achèvement suggère d’indexer séparément les suggestions, et une partie de celles-ci est toujours en mode de développement et ne traite pas du cas d’utilisation de la récupération des résultats de la recherche.
  • Les approches de temps d’index sont rapides car il y a moins de frais généraux pendant le temps de requête, mais elles impliquent plus de travail de grognement, comme la réindexation, la planification de la capacité et l’augmentation du coût du disque. Le temps de requête est facile à mettre en œuvre, mais les requêtes de recherche sont coûteuses. Ceci est très important à comprendre car la plupart du temps, les utilisateurs doivent en choisir un et comprendre ce compromis peut aider à résoudre de nombreux problèmes de performances.

Divers

Dans la plupart des cas, les solutions fournies par ES pour la saisie semi-automatique ne répondent pas aux exigences spécifiques de l’entreprise ou ont des impacts sur les performances des grands systèmes, car il ne s’agit pas de solutions uniques. La plupart du temps, les utilisateurs doivent modifier afin d’obtenir la solution optimisée (plus performante et tolérante aux pannes) et traiter les problèmes de performances d’Elasticsearch n’est pas anodin. Opster aide à les détecter tôt et fournit une assistance et les outils nécessaires pour les déboguer et les prévenir efficacement.

Pour de plus amples informations, veuillez consulter :

  1. Guide d’Opster sur la latence de recherche accrue pour obtenir des informations et améliorer les performances.
  2. Guide d’Opster sur l’utilisation des journaux de recherche lente sur la façon de déboguer rapidement les problèmes de recherche lente

Améliorer Les Performances D’Elasticsearch

Exécuter L’Analyse

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.