Hub de Connaissances DevOps
Hub de Connaissances DevOps

Diagnostic et résolution des requêtes de recherche Elasticsearch lentes

Vous rencontrez des problèmes avec des recherches Elasticsearch lentes ? Ce guide complet vous aide à identifier les goulots d'étranglement courants en matière de performance, des requêtes inefficaces et des problèmes de mappage aux limitations matérielles. Apprenez à diagnostiquer les requêtes lentes à l'aide des outils intégrés d'Elasticsearch et à mettre en œuvre des solutions concrètes pour des résultats de recherche plus rapides et plus réactifs. Optimisez votre cluster pour des performances maximales grâce à des conseils pratiques et des meilleures pratiques.

60 vues

Comprendre et résoudre les requêtes de recherche Elasticsearch lentes

Elasticsearch est un moteur de recherche et d'analyse distribué puissant, réputé pour sa vitesse et son évolutivité. Cependant, à mesure que les volumes de données augmentent et que la complexité des requêtes s'accroît, la dégradation des performances peut devenir un problème important. Des requêtes de recherche lentes frustrent non seulement les utilisateurs, mais peuvent également affecter la réactivité globale et l'efficacité des applications qui dépendent d'Elasticsearch. Ce guide vous aidera à diagnostiquer les causes courantes des requêtes de recherche lentes et vous fournira des solutions exploitables pour optimiser votre cluster Elasticsearch afin d'obtenir des résultats plus rapides.

Comprendre pourquoi vos recherches sont lentes est la première étape vers une solution. Cet article explorera divers aspects des performances d'Elasticsearch, des requêtes elles-mêmes à la configuration et au matériel sous-jacents du cluster. En abordant systématiquement ces goulots d'étranglement potentiels, vous pouvez améliorer considérablement la latence de recherche et garantir que votre implémentation Elasticsearch reste performante.

Causes courantes des recherches Elasticsearch lentes

Plusieurs facteurs peuvent contribuer à la lenteur des requêtes de recherche. L'identification de la cause spécifique dans votre environnement est cruciale 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 étendues : Requêtes qui scannent un grand nombre de documents ou de champs sans filtrage suffisant.
    • Exemple : Une requête match_all sur un index massif.
  • Pagination profonde : Demander un très grand nombre de résultats en utilisant from et size (pagination profonde). Les API search_after ou scroll par défaut d'Elasticsearch sont plus efficaces pour les grands ensembles de résultats.
  • Agrégaions complexes : Agrégaions trop compliquées ou gourmandes en ressources, surtout lorsqu'elles sont combinées avec des requêtes étendues.
  • Requêtes avec jokers (Wildcard Queries) : Les jokers de début (par exemple, *terme) sont particulièrement inefficaces car ils ne peuvent pas utiliser efficacement les recherches d'index inversé. Les jokers de fin sont généralement meilleurs mais peuvent toujours être lents sur de grands ensembles de données.
  • Requêtes par expressions régulières : Celles-ci peuvent être coûteuses en termes de 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 une recherche plus lente.

  • Mappings dynamiques : Bien que pratiques, les mappings dynamiques peuvent parfois entraîner des types de champs inattendus ou la création de champs analysés inutiles, augmentant la taille de l'index et les frais généraux de recherche.
  • Champs text vs. keyword : Utiliser des champs text pour la correspondance exacte ou le tri/les 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 ID de produit (PROD-123), il doit être mappé comme keyword, et non text.
      json PUT my-index { "mappings": { "properties": { "product_id": { "type": "keyword" } } } }
  • Champ _all (Déprécié/Supprimé) : Dans les anciennes versions, le champ _all indexait le contenu de tous les autres champs. Bien qu'il simplifiât les recherches simples, il augmentait considérablement la taille de l'index et les E/S. Les pratiques modernes d'Elasticsearch évitent de s'appuyer sur _all.
  • Structures de données imbriquées (Nested) : L'utilisation de types de données nested peut être puissante pour maintenir des relations, mais peut également être plus gourmande en ressources pour les requêtes par rapport aux types flattened ou object si elles ne sont pas interrogées 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 essentiel 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 la mémoire. Elasticsearch s'appuie également fortement sur le tas JVM et le cache du système de fichiers de l'OS.
    • 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 en 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 grands shards : Les grands shards peuvent entraîner de longs temps de récupération et une distribution inégale de la charge.
    • Directive générale : Visez des tailles de shard entre 10 Go et 50 Go. Le nombre optimal de shards dépend de votre volume de données, des modèles de requêtes et de la taille du cluster.
  • Répliques : Bien que les répliques améliorent la disponibilité et le débit de lecture, elles augmentent également la surcharge d'indexation et l'utilisation de l'espace disque. Trop de répliques peuvent épuiser les ressources.
  • Taille du tas JVM : Un tas JVM mal configuré peut entraîner des pauses fréquentes dues au ramasse-miettes, ce qui affecte la latence de recherche. La taille du tas ne doit généralement pas dépasser 50 % de la RAM de votre système, et idéalement pas plus de 30-32 Go.
  • 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 survenant lors de l'indexation peuvent indirectement avoir un impact sur la vitesse de recherche.

  • Charge d'indexation élevée : Si le cluster a du mal à suivre le rythme des requêtes 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 grand nombre de petits segments. Bien qu'Elasticsearch fusionne automatiquement les segments, 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 d'Elasticsearch (Slow Logs)

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

  • Configuration : Vous pouvez définir index.search.slowlog.threshold.query et index.search.slowlog.threshold.fetch dans les paramètres de votre index ou dynamiquement.
    json PUT _settings { "index": { "search": { "slowlog": { "threshold": { "query": "1s", "fetch": "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 des journaux : Les journaux lents se trouvent généralement dans les fichiers journaux d'Elasticsearch (elasticsearch.log).

2. Outils de Surveillance Elasticsearch

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

  • Elastic Stack Monitoring (anciennement X-Pack) : 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, et plus encore.
  • APM (Application Performance Monitoring) : Peut aider à tracer les requêtes 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 : Voyez comment une chaîne de requête est traitée.
    bash GET my-index/_analyze { "field": "my_text_field", "text": "Quick brown fox" }

4. API Profile

Pour l'optimisation des performances de requêtes très spécifiques, l'API Profile peut fournir des informations détaillées sur la synchronisation de chaque composant d'une requête de recherche.

  • Exemple :bash GET my-index/_search { "profile": true, "query": { "match": { "my_field": "search term" } } }

Résoudre les Requêtes Lentes : Solutions et Optimisations

Une fois la cause profonde identifiée, vous pouvez mettre en œuvre des solutions ciblées.

1. Optimisation des Requêtes

  • Contexte de filtre : Utilisez la clause filter au lieu de la clause must pour les requêtes qui ne nécessitent pas de score. Les filtres sont mis en cache et généralement plus rapides.
    json GET my-index/_search { "query": { "bool": { "must": [ { "match": { "title": "elasticsearch" } } ], "filter": [ { "term": { "status": "published" } }, { "range": { "publish_date": { "gte": "now-1M/M" } } } ] } } }
  • Évitez les jokers de début : Réécrivez les requêtes pour éviter les jokers de début (*terme) si possible. Envisagez d'utiliser des tokenizers ngram ou des méthodes de recherche alternatives.
  • Limitez les balayages 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 récupérer de grands ensembles de résultats, implémentez search_after ou l'API scroll.
  • Simplifiez les agrégations : Examinez et optimisez les agrégations complexes. Envisagez d'utiliser les 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 la correspondance exacte, le tri ou les agrégations sont mappés comme keyword.

2. Améliorer les 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.
  • Désactiver _source ou doc_values (Utiliser avec prudence) : Si vous n'avez pas besoin de récupérer le document original (_source) ou d'utiliser doc_values pour le tri/les agrégations sur certains champs, les désactiver peut économiser de l'espace disque et améliorer les performances. Cependant, cela n'est souvent pas recommandé pour une utilisation générale.
  • index_options : Pour les champs text, affinez les index_options pour stocker uniquement les informations nécessaires (par exemple, les positions pour les requêtes de phrases).

3. Réglage du Matériel et du Cluster

  • Mettre à niveau le matériel : Investissez dans des CPU plus rapides, plus de RAM et surtout des SSD.
  • Optimiser la stratégie de sharding : Révisez le nombre et la taille de vos 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 l'Index Lifecycle Management (ILM) pour gérer les index basés sur le temps et leur sharding.
  • Ajuster 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 ramasse-miettes.
  • Rôles des nœuds : Distribuez les rôles (master, data, ingest, coordinating) sur différents nœuds pour éviter les conflits de ressources.
  • Augmenter les répliques (pour les charges de travail intensives en lecture) : Si votre goulot d'étranglement est le débit de lecture et non l'indexation, envisagez d'ajouter plus de répliques, mais surveillez l'impact sur l'indexation.

4. Optimisation de l'Index

  • Fusion forcée (Force Merge) : Exécutez périodiquement une opération _forcemerge (en particulier sur les index en lecture seule) pour réduire le nombre de segments. Attention : Il s'agit d'une opération gourmande en ressources et doit être effectuée pendant les heures creuses.
    bash POST my-index/_forcemerge?max_num_segments=1
  • Gestion du cycle de vie des index (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

  • Surveiller régulièrement : La surveillance continue est essentielle pour détecter rapidement les régressions de performance.
  • Tester les changements : Avant de déployer des changements importants en production, testez-les dans un environnement de staging.
  • Comprendre vos données et requêtes : Les meilleures optimisations sont spécifiques au contexte. Sachez quelles données vous avez et comment vous les interrogez.
  • Maintenir Elasticsearch à jour : Les nouvelles versions incluent souvent des améliorations de performance et des corrections de bugs.
  • Dimensionner correctement votre cluster : Évitez le sur-provisionnement ou le sous-provisionnement des ressources. Évaluez régulièrement les besoins de votre cluster.

Conclusion

Diagnostiquer et résoudre les requêtes de recherche Elasticsearch lentes nécessite une approche systématique. En comprenant les causes courantes – requêtes inefficaces, mappings sous-optimaux et limitations matérielles/de configuration – et en utilisant des outils de diagnostic efficaces comme les journaux lents et la surveillance, vous pouvez identifier les goulots d'étranglement. La mise en œuvre d'optimisations ciblées, allant de l'ajustement des requêtes et des mappings aux mises à niveau matérielles et à la configuration du cluster, conduira à des performances de recherche significativement plus rapides, garantissant que votre déploiement Elasticsearch reste un atout performant pour vos applications.