Diagnostiquer et corriger les requêtes de recherche Elasticsearch lentes

Les recherches Elasticsearch lentes proviennent généralement de requêtes larges, d'agrégations coûteuses, de choix de mapping, de la disposition des shards ou de la pression sur les ressources du cluster. Si votre API de recherche commence à expirer ou si la latence augmente après la croissance d'un index, vous devez déterminer si la requête, l'index ou le cluster effectue trop de travail.

Utilisez les journaux lents et l'API Profile pour trouver la partie coûteuse, puis ajustez la requête, le mapping, la stratégie de sharding ou le matériel en fonction des preuves.

Coupables courants des recherches Elasticsearch lentes

Plusieurs facteurs peuvent contribuer à des requêtes de recherche lentes. Identifier la cause spécifique dans votre environnement est crucial pour un dépannage efficace.

1. Requêtes inefficaces

La conception des requêtes est souvent l'influence la plus directe sur les performances de recherche. Des requêtes complexes ou mal structurées peuvent forcer Elasticsearch à effectuer beaucoup de travail, entraînant une latence accrue.

Requêtes larges : Des requêtes qui analysent un grand nombre de documents ou de champs sans filtrage suffisant.
- Exemple : Une requête match_all sur un index massif.
Pagination profonde : Demander une très grande page en utilisant from et size. Pour la pagination profonde côté utilisateur, préférez search_after avec un tri stable et une recherche point-in-time. Utilisez scroll principalement pour le traitement par lots ou les charges de travail de type réindexation.
Agrégations complexes : Des agrégations trop compliquées ou gourmandes en ressources, surtout lorsqu'elles sont combinées avec des requêtes larges.
Requêtes avec jokers : Les jokers en tête (par exemple, *terme) sont particulièrement inefficaces car ils ne peuvent pas utiliser efficacement les recherches dans l'index inversé. Les jokers en fin de chaîne sont généralement meilleurs mais peuvent encore être lents sur de grands ensembles de données.
Requêtes d'expressions régulières : Elles peuvent être coûteuses en calcul et doivent être utilisées avec parcimonie.

2. Problèmes de mapping

La façon dont vos données sont indexées (définie par vos mappings) a un impact profond sur la vitesse de recherche. Des choix de mapping incorrects peuvent entraîner une indexation inefficace et des recherches plus lentes.

Mappings dynamiques : Bien que pratiques, les mappings dynamiques peuvent parfois conduire à des types de champs inattendus ou à la création de champs analyzed inutiles, augmentant la taille de l'index et la surcharge de recherche.
Champs text vs keyword : Utiliser des champs text pour des correspondances exactes ou des tris/agrégations alors qu'un champ keyword serait plus approprié. Les champs text sont analysés pour la recherche en texte intégral, tandis que les champs keyword sont indexés tels quels, ce qui les rend idéaux pour les correspondances exactes, le tri et les agrégations.
- Exemple : Si vous devez filtrer par un ID de produit (PROD-123), il doit être mappé comme keyword, pas text.
```
PUT mon-index
{
  "mappings": {
    "properties": {
      "product_id": {
        "type": "keyword"
      }
    }
  }
}
```
Anciennes hypothèses sur le champ _all : Les anciennes versions d'Elasticsearch avaient un champ _all qui indexait le contenu d'autres champs. Les versions modernes l'ont supprimé, utilisez donc des champs explicites ou copy_to lorsque vous avez besoin d'un texte de recherche combiné.
Structures de données imbriquées : L'utilisation de types de données nested peut être puissante pour maintenir les relations, mais peut aussi être plus gourmande en ressources pour les requêtes par rapport aux types flattened ou object si elle n'est pas interrogée avec soin.

3. Configuration matérielle et du cluster

L'infrastructure sous-jacente et la façon dont Elasticsearch est configuré jouent un rôle critique dans les performances.

Ressources matérielles insuffisantes :
- CPU : Une utilisation élevée du CPU peut indiquer des requêtes inefficaces ou des charges d'indexation/recherche lourdes.
- RAM : Une RAM insuffisante entraîne une augmentation des E/S disque car le système d'exploitation échange de la mémoire. Elasticsearch dépend également fortement du tas JVM et du cache du système de fichiers du système d'exploitation.
- E/S disque : Les disques lents (en particulier les HDD) sont un goulot d'étranglement majeur. L'utilisation de SSD est fortement recommandée pour les clusters Elasticsearch de production.
Taille et nombre de shards :
- Trop de petits shards : Chaque shard a une surcharge. Un très grand nombre de petits shards peut submerger le cluster.
- Trop peu de gros shards : Les gros shards peuvent entraîner des temps de récupération longs et une répartition inégale de la charge.
- Directive générale : Les shards de quelques dizaines de gigaoctets sont courants pour de nombreuses charges de travail de journalisation et de recherche, mais la bonne taille dépend du volume de données, des modèles de requête, des objectifs de récupération et des ressources du nœud.
Réplicas : Bien que les réplicas améliorent la disponibilité et le débit de lecture, ils augmentent également la surcharge d'indexation et l'utilisation de l'espace disque. Trop de réplicas peuvent solliciter les ressources.
Taille du tas JVM : Un tas JVM mal configuré peut entraîner des pauses de garbage collection. Un point de départ courant est de ne pas dépasser la moitié de la RAM système, tout en laissant suffisamment de mémoire pour le cache du système de fichiers du système d'exploitation. Suivez les directives de tas de votre version d'Elasticsearch.
Latence réseau : Dans les environnements distribués, la latence réseau entre les nœuds peut affecter la communication inter-nœuds et la coordination de la recherche.

4. Problèmes de performances d'indexation affectant la recherche

Bien que cet article se concentre sur la recherche, les problèmes lors de l'indexation peuvent avoir un impact indirect sur la vitesse de recherche.

Charge d'indexation élevée : Si le cluster a du mal à suivre le rythme des demandes d'indexation, cela peut avoir un impact sur les performances de recherche. Cela est souvent dû à un matériel insuffisant ou à des stratégies d'indexation mal optimisées.
Nombre élevé de segments : Une indexation fréquente sans fusion régulière des segments peut entraîner un nombre élevé de petits segments. Bien qu'Elasticsearch fusionne les segments automatiquement, ce processus est gourmand en ressources et peut temporairement ralentir les recherches.

Diagnostiquer les requêtes lentes

Avant de mettre en œuvre des correctifs, vous devez identifier quelles requêtes sont lentes et pourquoi.

1. Journaux lents Elasticsearch

Configurez Elasticsearch pour journaliser les requêtes lentes. C'est le moyen le plus direct d'identifier les demandes de recherche problématiques.

Configuration : Définissez des seuils de journal lent par index. Utilisez les suffixes de niveau de journal attendus par Elasticsearch, tels que warn, info, debug ou trace.
```
PUT _settings
{
  "index": {
    "search": {
      "slowlog": {
        "threshold": {
          "query": {
            "warn": "1s"
          },
          "fetch": {
            "warn": "1s"
          }
        }
      }
    }
  }
}
```
- query : Journalise les requêtes qui prennent plus de temps que le seuil spécifié pour exécuter la phase de requête.
- fetch : Journalise les requêtes qui prennent plus de temps que le seuil spécifié pour exécuter la phase de récupération (récupération des documents réels).
Emplacement du journal : Les journaux lents sont écrits via la journalisation Elasticsearch et apparaissent souvent dans des fichiers de journal lents de recherche séparés en fonction de votre package, de votre plateforme de déploiement et de votre configuration de journalisation.

2. Outils de surveillance Elasticsearch

Utilisez des outils de surveillance pour obtenir des informations sur la santé et les performances du cluster.

Surveillance Elastic Stack : Fournit des tableaux de bord pour le CPU, la mémoire, les E/S disque, l'utilisation du tas JVM, la latence des requêtes, les taux d'indexation, etc., lorsqu'elle est configurée.
APM (Application Performance Monitoring) : Peut aider à tracer les demandes de votre application vers Elasticsearch, en identifiant les goulots d'étranglement au niveau de l'application ou d'Elasticsearch.
Outils tiers : De nombreux outils externes offrent des capacités avancées de surveillance et d'analyse.

3. API Analyze

L'API _analyze peut aider à comprendre comment vos champs de texte sont tokenisés et traités, ce qui est crucial pour déboguer les problèmes de recherche en texte intégral.

Exemple : Voir comment une chaîne de requête est traitée.

GET mon-index/_analyze
{
  "field": "mon_champ_texte",
  "text": "Renard brun rapide"
}

4. API Profile

Pour un réglage très spécifique des performances des requêtes, l'API Profile peut fournir des informations de synchronisation détaillées pour chaque composant d'une demande de recherche.

Exemple :

GET mon-index/_search
{
  "profile": true,
  "query": {
    "match": {
      "mon_champ": "terme de recherche"
    }
  }
}

Corriger les requêtes lentes : solutions et optimisations

Une fois que vous avez identifié la cause première, vous pouvez mettre en œuvre des solutions ciblées.

1. Optimisation des requêtes

Contexte de filtre : Utilisez la clause filter pour les conditions qui n'ont pas besoin de scoring. Elasticsearch peut les exécuter comme des filtres oui/non et peut mettre en cache les filtres fréquemment utilisés.

GET mon-index/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "title": "elasticsearch" } }
      ],
      "filter": [
        { "term": { "status": "published" } },
        { "range": { "publish_date": { "gte": "now-1M/M" } } }
      ]
    }
  }
}

Évitez les jokers en tête : Réécrivez les requêtes pour éviter les jokers en tête (*terme) si possible. Envisagez d'utiliser des tokenizers ngram ou d'autres méthodes de recherche alternatives.
Limitez les analyses de champs : Spécifiez uniquement les champs dont vous avez besoin dans votre requête et dans le filtrage _source de votre réponse.
Utilisez search_after pour la pagination profonde : Pour la pagination interactive au-delà des pages superficielles, utilisez search_after avec un tri déterministe. Pour les exportations volumineuses, utilisez scroll ou point-in-time plus search_after, selon votre version d'Elasticsearch et votre charge de travail.
Simplifiez les agrégations : Examinez et optimisez les agrégations complexes. Envisagez d'utiliser des agrégations composite pour la pagination profonde des agrégations.
keyword pour les correspondances exactes/le tri : Assurez-vous que les champs utilisés pour les correspondances exactes, le tri ou les agrégations sont mappés comme keyword.

2. Amélioration des mappings

Mappings explicites : Définissez des mappings explicites pour vos index plutôt que de vous fier uniquement aux mappings dynamiques. Cela garantit que les champs sont indexés avec les types corrects.
Soyez prudent avec _source et doc_values : La désactivation de _source peut casser les mises à jour, la réindexation, la mise en évidence et les flux de travail de débogage. La désactivation de doc_values sur les champs utilisés pour le tri ou les agrégations nuira à ces charges de travail. Traitez-les comme des optimisations de stockage, pas comme des correctifs de recherche par défaut.
index_options : Pour les champs text, affinez index_options pour stocker uniquement les informations nécessaires (par exemple, les positions pour les requêtes de phrase).

3. Réglage du matériel et du cluster

Mettez à niveau le matériel : Investissez dans des CPU plus rapides, plus de RAM et surtout des SSD.
Optimisez la stratégie de sharding : Examinez votre nombre et votre taille de shards. Envisagez de réindexer les données dans un nouvel index avec une stratégie de sharding optimisée si nécessaire. Utilisez des outils comme Index Lifecycle Management (ILM) pour gérer les index basés sur le temps et leur sharding.
Ajustez le tas JVM : Assurez-vous que le tas JVM est correctement dimensionné (par exemple, 50 % de la RAM, max 30-32 Go) et surveillez le garbage collection.
Rôles des nœuds : Répartissez les rôles (maître, données, ingestion, coordination) sur différents nœuds pour éviter la contention des ressources.
Augmentez les réplicas (pour les charges de travail à forte lecture) : Si votre goulot d'étranglement est le débit de lecture et non l'indexation, envisagez d'ajouter plus de réplicas, mais surveillez l'impact sur l'indexation.

4. Optimisation de l'index

Force Merge : Exécutez _forcemerge uniquement sur les index en lecture seule où moins de segments aideront la recherche et le stockage. C'est gourmand en ressources et peut créer de très gros segments qui sont coûteux à réécrire si l'index continue de recevoir des écritures.
```
POST mon-index/_forcemerge?max_num_segments=1
```
Index Lifecycle Management (ILM) : Utilisez ILM pour gérer automatiquement les index, y compris les phases d'optimisation comme la fusion forcée sur les index plus anciens et inactifs.

Bonnes pratiques pour maintenir les performances

Surveillez régulièrement : Une surveillance continue est essentielle pour détecter rapidement les régressions de performances.
Testez les modifications : Avant de déployer des modifications importantes en production, testez-les dans un environnement de préproduction.
Comprenez vos données et vos requêtes : Les meilleures optimisations sont spécifiques au contexte. Sachez quelles données vous avez et comment vous les interrogez.
Gardez Elasticsearch à jour : Les versions plus récentes incluent souvent des améliorations de performances et des corrections de bugs.
Dimensionnez correctement votre cluster : Évitez le sur-approvisionnement ou le sous-approvisionnement des ressources. Évaluez régulièrement les besoins de votre cluster.

À retenir

Corrigez les recherches Elasticsearch lentes en mesurant d'abord. Les journaux lents vous indiquent quelles demandes sont problématiques, l'API Profile montre où le temps est passé, et les métriques du cluster montrent si la requête est en concurrence avec la pression du tas, les E/S disque, l'indexation ou la surcharge des shards. Faites un changement, réexécutez la même requête, et ne conservez le résultat que si la latence et l'utilisation des ressources s'améliorent.