Guide des performances d'indexation Elasticsearch : Les meilleures pratiques dévoilées

Guide des performances d'indexation Elasticsearch : Bonnes pratiques dévoilées

Elasticsearch est un moteur de recherche et d'analyse distribué puissant, réputé pour sa vitesse et son évolutivité. Cependant, l'obtention de performances optimales, en particulier pendant la phase d'indexation, exige un examen attentif de divers paramètres et stratégies. L'indexation, le processus d'ajout de documents à Elasticsearch, peut devenir un goulot d'étranglement si elle n'est pas correctement gérée, ce qui a un impact sur la réactivité globale et le débit de votre cluster. Ce guide abordera les aspects critiques des performances d'indexation Elasticsearch, dévoilant les meilleures pratiques pour augmenter considérablement vos taux d'ingestion de données.

Comprendre et mettre en œuvre ces techniques est crucial pour toute application s'appuyant sur Elasticsearch pour l'analyse de données en temps réel ou la recherche. Que vous traitiez d'énormes ensembles de données ou de mises à jour fréquentes, maîtriser l'optimisation de l'indexation garantira que votre cluster Elasticsearch reste un atout hautement performant. Nous explorerons les paramètres de configuration clés, les stratégies d'indexation en masse efficaces et l'impact des choix de mappage sur votre débit d'indexation.

Comprendre le processus d'indexation

Avant de plonger dans l'optimisation, il est essentiel de comprendre comment Elasticsearch gère l'indexation. Lorsqu'un document est indexé, Elasticsearch effectue plusieurs opérations : analyse du document, analyse des champs (tokenisation, racinisation, etc.), puis stockage de l'index inversé et d'autres structures de données. Ces opérations, en particulier l'analyse et les E/S disque, sont intensives en termes de CPU et d'E/S. Dans un environnement distribué, ces opérations sont gérées par des nœuds individuels, ce qui rend la configuration à l'échelle du cluster et les ressources des nœuds essentielles.

Facteurs clés influençant la vitesse d'indexation

Plusieurs facteurs peuvent avoir un impact significatif sur la vitesse à laquelle Elasticsearch peut indexer des documents :

Ressources matérielles : Le CPU, la RAM et surtout la vitesse des E/S disque sont primordiaux. Les SSD sont fortement recommandés par rapport aux disques durs pour leurs performances de lecture/écriture supérieures.
Configuration du cluster : L'allocation des shards, les paramètres de réplication et les rôles des nœuds jouent un rôle.
Stratégie d'indexation : La méthode utilisée pour envoyer des données (par exemple, requêtes de documents uniques vs API en masse).
Mappage et types de données : Comment vos champs sont définis et leurs types de données correspondants.
Intervalle de rafraîchissement : La fréquence à laquelle les données deviennent visibles pour la recherche.
Paramètres Translog : Paramètres de durabilité pour les segments Lucene.

Optimisation des performances d'indexation : Bonnes pratiques

Cette section couvre les stratégies exploitables pour améliorer le débit d'indexation de votre Elasticsearch.

1. Tirer parti de l'API en masse (Bulk API)

L'optimisation la plus fondamentale pour l'indexation est d'utiliser l'API en masse (Bulk API). Au lieu d'envoyer des requêtes d'indexation individuelles, ce qui entraîne une surcharge réseau et un coût de traitement par requête, l'API en masse vous permet d'envoyer une liste d'opérations (indexation, création, mise à jour, suppression) dans une seule requête HTTP. Cela réduit considérablement la latence du réseau et améliore le débit global.

Meilleures pratiques pour l'API en masse :

Taille des lots : Expérimentez avec les tailles des lots. Un point de départ courant est de 1 000 à 5 000 documents par lot, ou une taille de charge utile de 5 à 15 Mo. Un lot trop petit entraîne une inefficacité ; un lot trop grand peut entraîner des problèmes de mémoire côté client ou serveur.
Concurrence : Utilisez plusieurs threads ou des clients asynchrones pour envoyer des requêtes en masse simultanément. Cependant, évitez de surcharger votre cluster. Surveillez l'utilisation du CPU et des E/S pour trouver le point d'équilibre.
Gestion des erreurs : Mettez en œuvre une gestion robuste des erreurs. L'API en masse renvoie un tableau de réponses, et vous devez vérifier le statut de chaque opération.

Exemple de requête en masse :

POST /_bulk
{
  "index" : { "_index" : "my-index", "_id" : "1" }
}
{
  "field1" : "value1", 
  "field2" : "value2"
}
{
  "index" : { "_index" : "my-index", "_id" : "2" }
}
{
  "field1" : "value3", 
  "field2" : "value4"
}

2. Ajuster les paramètres d'indexation

Elasticsearch propose plusieurs paramètres qui peuvent être ajustés pour optimiser le processus d'indexation. Ceux-ci sont généralement définis par index.

Intervalle de rafraîchissement (`index.refresh_interval`)

L'intervalle de rafraîchissement contrôle la fréquence à laquelle les données deviennent visibles pour la recherche. Par défaut, il est réglé sur 1s. Pendant une indexation intensive, vous pouvez augmenter cet intervalle pour réduire la fréquence de création de segments, qui est une opération intensive en E/S. Le régler sur -1 désactive les rafraîchissements automatiques, ce qui signifie que les données ne seront pas consultables tant que vous n'aurez pas rafraîchi manuellement ou que l'index n'aura pas été fermé.

Recommandation : Pour les opérations d'indexation en masse, réglez index.refresh_interval à 30s ou 60s (ou même plus). Une fois l'opération en masse terminée, n'oubliez pas de le réinitialiser à une valeur inférieure (par exemple, 1s) pour une consultabilité quasi en temps réel.

Exemple utilisant l'API des paramètres d'index :

# Temporarily disable refresh
PUT /my-index/_settings
{
  "index" : {
    "refresh_interval" : "-1"
  }
}

# ... perform bulk indexing ...

# Re-enable refresh
PUT /my-index/_settings
{
  "index" : {
    "refresh_interval" : "1s"
  }
}

Durabilité du Translog (`index.translog.durability`)

Le translog est un journal d'écriture anticipée qui assure la durabilité des données. Il peut être réglé sur request (par défaut) ou async. Le régler sur async vide le translog de manière asynchrone, ce qui peut améliorer la vitesse d'indexation mais comporte un léger risque de perte de données si un nœud échoue avant que le translog ne soit écrit sur le disque.

Recommandation : Pour les scénarios d'importation en masse où la durabilité est moins critique que la vitesse, async peut être bénéfique. Tenez toujours compte de la tolérance de votre application à la perte de données.

Nombre de répliques (`index.number_of_replicas`)

Les répliques sont des copies de vos shards primaires, utilisées pour la haute disponibilité et la mise à l'échelle en lecture. Cependant, chaque réplique doit traiter chaque opération d'indexation. Lors des chargements initiaux de grandes quantités de données, régler index.number_of_replicas à 0 peut accélérer considérablement l'indexation. Une fois les données chargées, vous pouvez augmenter le nombre de répliques.

Exemple pendant le chargement en masse :

# Temporarily set replicas to 0
PUT /my-index/_settings
{
  "index" : {
    "number_of_replicas" : "0"
  }
}

# ... perform bulk indexing ...

# Restore replicas (e.g., to 1)
PUT /my-index/_settings
{
  "index" : {
    "number_of_replicas" : "1"
  }
}

3. Optimiser les mappages

Les mappages définissent la manière dont les documents et leurs champs sont stockés et indexés. Des mappages mal conçus peuvent entraîner des problèmes de performance.

Évitez le mappage dynamique pour les grands ensembles de données : Bien que pratique, le mappage dynamique peut entraîner des explosions de mappage et des types de champs inattendus. Définissez des mappages explicites pour vos index, en particulier pour les données à volume élevé.
Choisissez des types de données appropriés : Utilisez les types de données les plus efficaces. Par exemple, keyword est plus efficace pour la correspondance exacte de valeurs que text si la recherche en texte intégral n'est pas requise.
Désactivez les fonctionnalités inutiles : Si vous n'avez pas besoin de fonctionnalités comme norms pour un champ spécifique (par exemple, pour les correspondances exactes ou les agrégations), les désactiver peut économiser de l'espace et améliorer la vitesse d'indexation (norms: false). De même, désactivez doc_values si elles ne sont pas nécessaires pour le tri ou les agrégations sur un champ. Cependant, doc_values sont généralement bénéfiques pour les agrégations et le tri, il s'agit donc d'une décision nuancée.
Champ _source : Si vous n'avez pas besoin du document JSON original, désactiver _source peut économiser de l'espace disque et quelques E/S, mais cela empêche la réindexation et rend le débogage plus difficile. Envisagez la compression de _source si vous le maintenez activé.

Exemple de mappage (avec types explicites et norms désactivés) :

PUT /my-index
{
  "mappings": {
    "properties": {
      "timestamp": {"type": "date"},
      "message": {"type": "text", "norms": false},
      "user_id": {"type": "keyword"}
    }
  }
}

4. Considérations sur le matériel et l'infrastructure

Même avec des configurations logicielles parfaites, un matériel inadéquat limitera la vitesse d'indexation.

E/S disque : Utilisez des SSD rapides. Les SSD NVMe offrent les meilleures performances. Évitez le stockage en réseau (NAS) pour les nœuds d'indexation si possible.
CPU et RAM : Des cœurs de CPU suffisants sont nécessaires pour l'analyse, et une RAM abondante aide au cache et aux performances globales de la JVM.
Nœuds d'indexation dédiés : Pour des taux d'ingestion très élevés, envisagez de dédier des nœuds spécifiques de votre cluster uniquement à l'indexation. Cela sépare les charges de travail d'indexation des charges de travail de recherche, empêchant l'une d'affecter l'autre.
Réseau : Assurez une bande passante suffisante et une faible latence entre vos clients et les nœuds Elasticsearch, et entre les nœuds du cluster.

5. Taille et nombre des shards

Bien qu'il ne s'agisse pas directement d'un paramètre d'indexation, le nombre et la taille des shards ont un impact sur les performances. Trop de petits shards peuvent augmenter la surcharge. Inversement, un seul shard massif peut être difficile à gérer et peut ne pas bien évoluer. Visez des tailles de shard entre 10 Go et 50 Go pour des performances optimales, mais cela peut varier.

Recommandation : Planifiez le nombre de vos shards primaires avant d'indexer de grandes quantités de données. Il n'est généralement pas recommandé de modifier le nombre de shards primaires sur un index existant sans réindexer.

6. Gestion du cycle de vie des index (ILM)

Pour les données de séries temporelles, l'utilisation de la gestion du cycle de vie des index (ILM) est cruciale. Bien que l'ILM aide principalement à gérer les index au fil du temps (rollover, shrink, delete), l'action de rollover peut être configurée pour créer de nouveaux index en fonction de la taille ou de l'âge. Cela garantit que les index restent dans des plages de taille optimales, ce qui bénéficie indirectement aux performances d'indexation.

Rollover : Lorsqu'un index atteint une certaine taille ou un certain âge, l'ILM peut automatiquement créer un nouvel index vide et y basculer l'alias de flux de données. Cela vous permet d'optimiser les paramètres du nouvel index (par exemple, moins de répliques pendant le chargement initial en masse) et de maintenir les index actifs gérables.

Conclusion

L'optimisation des performances d'indexation d'Elasticsearch est une tâche à multiples facettes impliquant un ajustement minutieux des paramètres du cluster, une utilisation intelligente de l'API en masse, une conception de mappage réfléchie et un matériel approprié. En mettant en œuvre les meilleures pratiques décrites dans ce guide – tirer parti de l'API en masse, ajuster les intervalles de rafraîchissement et le nombre de répliques, optimiser les mappages et assurer une infrastructure robuste – vous pouvez améliorer considérablement vos taux d'ingestion de données et garantir que votre cluster Elasticsearch évolue efficacement avec vos besoins en données.

N'oubliez pas que les paramètres optimaux dépendent souvent de votre cas d'utilisation spécifique, du volume de données et du matériel. Une surveillance continue et des tests itératifs sont essentiels pour trouver la meilleure configuration pour votre environnement. Priorisez ces optimisations, en particulier lorsque vous traitez de grands volumes de données ou des exigences d'ingestion en temps réel exigeantes.