guide
Après avoir résumé un grand nombre de cas et passé en revue les pièges, cet article résume certaines techniques d'optimisation couramment utilisées et les directives d'évitement des pièges pour les clusters Elastisearch en termes d'optimisation des performances d'écriture.
Dans le processus de service aux clients Tencent Cloud ES, nous recevons souvent des commentaires de certains clients selon lesquels les performances de lecture et d'écriture des clusters ES sur le cloud n'ont pas répondu aux attentes, et nous espérons que nous pourrons coopérer pour effectuer des tests et des réglages de pression de performance. Après avoir combiné les scénarios commerciaux du client et une analyse approfondie des goulots d'étranglement des performances du cluster, nous pouvons essentiellement donner aux clients des suggestions et des mesures d'optimisation susceptibles d'améliorer considérablement les performances de lecture et d'écriture.
Sur la base de l'expérience pratique de nombreux grands clusters de clients, l'équipe Tencent Cloud Big Data ES a résumé certaines techniques d'optimisation couramment utilisées et les directives d'évitement des pièges pour les clusters Elastisearch en termes d'optimisation des performances d'écriture.
Analyse du principe de l'indice de cluster ES
Avant de présenter l'optimisation des performances d'écriture du cluster ES, examinons brièvement le processus de base de l'indexation du cluster Elastisearch. Comme le montre la figure 1 ci-dessous.
Figure 1. Diagramme schématique du processus d'écriture de l'index de cluster ES
En analysant la moitié gauche de la figure 1, on peut voir que le flux de base de l'écriture ES est le suivant :
1. Le client envoie une demande de document d'indexation à Node1 ;
2. Node1 détermine que le document appartient à la partition 0 selon doc_id et transmet la demande à Node3
3. Node3 exécute la demande sur le fragment principal et transmet la demande en parallèle au nœud où se trouve le fragment de réplique après le succès. Une fois que tous les fragments de réplique ont été écrits avec succès, Node3 renvoie le succès de l'écriture au nœud de coordination, et le nœud de coordination signale au client que le document doc a été écrit avec succès.
En analysant la moitié droite de la figure 1, nous pouvons voir que la logique d'exécution spécifique des documents écrits sur le cluster ES sur une partition est principalement divisée en quatre étapes clés, comme le montre la figure 2 ci-dessous.
Figure 2. Diagramme schématique du processus principal d'écriture du cluster ES
1. Processus d'écriture :
Après avoir reçu la demande d'écriture du nœud de coordination, le nœud où se trouve le fragment écrira d'abord le document dans un tampon en mémoire, également appelé tampon d'indexation. À ce moment, le document est toujours introuvable. Lorsque l'espace du tampon en mémoire est plein, le document dans le tampon en mémoire sera automatiquement généré dans un fichier de segment, puis le document sera recherché.
2. Processus d'actualisation :
Dans le processus d'écriture ci-dessus, doc sera d'abord écrit dans le tampon en mémoire, et les données dans le tampon en mémoire seront effacées dans deux cas : le premier cas est lorsque l'espace du tampon en mémoire mentionné ci-dessus est effacé Après s'il est plein, ES l'effacera automatiquement et générera un segment.Le deuxième cas est l'opération de rafraîchissement déclenchée par le minutage ES, qui est exécutée toutes les 1 s par défaut. Le processus d'actualisation est en fait le processus d'écriture des données du tampon en mémoire dans le cache du système de fichiers, et ce processus générera également un fichier de segment.
3. Processus de rinçage :
Le processus d'écriture ci-dessus consiste à écrire le document dans le tampon en mémoire, et le processus d'actualisation consiste à actualiser le document dans le cache du système de fichiers. Les données de ces deux processus sont toujours en mémoire, une fois que la machine tombe en panne ou redémarre, il peut y avoir un risque de perte de données. Pour la perte de données, ES utilise le mécanisme translog pour assurer la fiabilité des données. Le mécanisme de mise en œuvre consiste à écrire le document sous forme de clé-valeur dans le fichier translog en même temps après avoir reçu la demande d'écriture. Lorsque les données dans le cache du système de fichiers est vidé sur le disque, il sera effacé et le processus de vidage des données dans le cache du système de fichiers est l'opération Flush. On peut également voir sur la figure 2 qu'après l'exécution de l'opération Flush, les données dans le tampon en mémoire et le translog seront effacées.
4. Processus de fusion :
Chaque opération d'actualisation d'ES générera un nouveau fichier de segment de segment. Cela conduira à une montée en flèche du nombre de fichiers en peu de temps. Trop de segments entraîneront une série de problèmes, tels que la consommation d'un grand nombre de descripteurs de fichiers, la consommation de mémoire et de cycles de fonctionnement du processeur. Et chaque demande de recherche doit vérifier tour à tour chaque fichier de segment, ce qui entraîne une baisse significative des performances de recherche. Afin de résoudre ce problème, Elasticearch fusionne régulièrement ces fichiers de segments en maintenant un thread en arrière-plan, fusionne de petits segments en grands segments, puis fusionne de grands segments en segments plus grands. Ce processus de fusion est le processus de Segment Merge.
Optimisation des performances d'écriture du cluster ES
1. Scénarios de synchronisation combinés à l'écriture d'index de défilement dynamique ILM
Pour les scénarios tels que les journaux, la surveillance et l'APM, il est recommandé de combiner la gestion du cycle de vie des index (ILM) et la gestion du cycle de vie des instantanés (SLM). Utilisez ILM pour contrôler de manière flexible la taille de l'index écrit, en particulier en cas d'augmentation soudaine du trafic, afin que les performances d'écriture ne soient pas affectées en raison de la capacité excessive d'un seul index.
Certains clients sur notre cloud organisent souvent certaines activités opérationnelles, telles que des festivals de shopping e-commerce, etc. Au cours des activités opérationnelles, la quantité de journaux générés par l'entreprise est souvent plusieurs fois, voire dix fois supérieure à la quantité normale. Si vous créez un index tous les jours, l'index ce jour-là deviendra très volumineux pendant l'événement, et il dépassera facilement le principe de conception officiellement recommandé de "contrôler la taille d'un seul fragment dans les 30 à 50 Go". Cela déclenchera une série de problèmes et affectera même les performances. Par exemple, lorsqu'un seul fragment est trop volumineux, cela affectera la vitesse de déplacement des fragments et l'efficacité de la récupération des fragments après un redémarrage anormal des nœuds, et déclenchera même à l'avance la limite supérieure de 2,1 milliards de documents dans un seul fragment, ce qui entraînera perte de données.
Combiné avec la gestion du cycle de vie de l'index, nous pouvons concevoir de manière flexible des stratégies de roulement d'index, telles que commencer à rouler après un jour, commencer à rouler lorsque l'index atteint 1T et commencer à rouler lorsque le nombre de documents atteint 10. Toute condition qui se déclenche en premier sera rouler jusqu'au nouvel index suivant pour écrire enter. De cette manière, la taille de chaque index et fragment peut être bien contrôlée dans une plage stable. Pour plus de détails sur la gestion du cycle de vie des index, veuillez vous reporter à « Principes et pratiques de gestion du cycle de vie des index Tencent Cloud Elasticsearch ».
2. Ne spécifiez pas doc_id lors de l'écriture des données, laissez ES générer automatiquement
Spécifier le doc_id à écrire vérifiera si le doc existe avant l'écriture. S'il existe, il effectuera une opération de mise à jour, et s'il n'existe pas, il effectuera une opération d'insertion. Par conséquent, spécifier un doc_id à écrire consommera plus de CPU , la charge et les E/S disque du cluster. Nous avons précédemment comparé et analysé les données de performances d'écriture d'un grand client achetant en groupe dans la communauté en spécifiant doc_id et en ne spécifiant pas doc_id. Dans le cas de la spécification de doc_id à écrire, l'utilisation du processeur a augmenté de 30 % et IOutils a augmenté de 42 %.
3. Utilisez l'interface en masse pour écrire des données par lots, et la taille de chaque donnée en masse est d'environ 10M
Afin d'améliorer les performances d'écriture, ES fournit une API appelée écriture en masse. L'écriture de cette API permet au client d'envoyer plusieurs documents doc au nœud de coordination pour écriture. La taille du document ou le nombre de documents écrits par lots détermine directement le facteur clé des performances d'écriture. Après de nombreux tests et recommandations officielles, il est idéal de contrôler la quantité de données écrites dans chaque bloc à 10 Mo. Si calculé par un doc1k, il est recommandé de contrôler le nombre de documents dans un lot de bloc entre 8 000 et 20 000. Nous pouvons utiliser l'API _tasks pour vérifier si le nombre de documents définis se situe dans une plage raisonnable.
GET_tasks?detailed=true&human&group_by=parents&actions=indices:data/write/bulk
Figure 3. API _tasks pour afficher les détails de l'écriture en masse
4. Activer bulk_routing pour transférer les requêtes vers moins de fragments
Par défaut, après l'envoi d'un lot d'écritures en masse du client au nœud de coordination, le nœud de coordination divise d'abord le lot de documents en plusieurs parties en fonction du nombre de fragments selon une certaine politique localement, et les envoie en parallèle à les nœuds où se trouvent les fragments principaux. , puis le nœud de coordination reviendra au client après avoir attendu que tous les nœuds où se trouvent les fragments renvoient un accusé de réception d'écriture réussi. Par conséquent, le temps d'écriture de ce lot de vrac dépendra directement du nœud avec le temps de réponse le plus lent, ce qui est un effet de longue traîne typique.
Afin de résoudre ce problème, l'équipe Tencent Cloud ES a développé la fonctionnalité avancée de bulk_routing. En générant de manière aléatoire un routage sur le nœud de coordination, chaque lot d'écritures en masse n'est transmis qu'à un nœud de partition spécifique. De cette manière, la surcharge du réseau et l'utilisation du processeur pendant le processus d'écriture sont réduites et les partitions à longue traîne sont évitées. affecter les performances d'écriture globales. Nous pouvons activer le routage en vrac via l'API suivante. Après avoir observé le cluster de journaux d'un grand client qui a activé le routage en vrac, nous avons constaté que, par rapport à la non-activation du routage en vrac, la valeur maximale d'écriture a augmenté de 25 % et l'utilisation du processeur a diminué de 20 %. Et lorsque le nombre de nœuds est plus élevé, l'amélioration des performances est plus évidente.
PUT my-index/_settings
{
"index.bulk_routing.enabled": true
}5. Pour les clusters à grande échelle, créez des index à l'avance et utilisez un mappage d'index fixe
L'échelle du cluster est grande, généralement la capacité d'index et le nombre total de fragments seront relativement importants. Étant donné que la mise à jour des métadonnées est impliquée lors de la création d'un index et de la mise à jour du mappage, cela bloquera temporairement l'écriture pendant le processus de mise à jour. métadonnées sur le maître Si à ce moment Si la quantité d'écriture est importante, cela peut entraîner l'abandon de l'écriture à zéro. La figure 4 ci-dessous est une capture d'écran du journal où des zéros ont été écrits en raison du délai de mise à jour du mappage lorsqu'un client de notre cloud a changé d'index à 8h00 tous les matins. Cependant, si l'index peut être créé à l'avance et qu'un modèle d'index fixe est utilisé, un grand nombre d'opérations de mise à jour des métadonnées peuvent être évitées lors du changement d'index, garantissant ainsi la stabilité et les performances d'écriture du cluster.
Figure 4. Capture d'écran du délai d'expiration du mappage de mise à jour du cluster
6. Définissez le mappage à l'avance et réduisez le nombre de champs d'index
Pour les champs qui ne participeront pas à la récupération, en particulier les champs binaires et les champs de texte super longs, vous pouvez définir l'attribut d'index du champ d'index sur non analysé ou non, c'est-à-dire que nous n'effectuons pas la segmentation des mots et la construction de l'index De cette manière, les opérations inutiles et la surcharge des performances du processeur peuvent être réduites, améliorant ainsi les performances d'écriture du cluster. La figure 5 ci-dessous est un test de performances que nous avons effectué. Lorsque nous définissons tous les attributs de champ sur index et effectuons à nouveau le test de pression d'écriture, nous pouvons voir que l'utilisation du processeur a grimpé jusqu'à 90 %.
Figure 5. L'utilisation du processeur du cluster après l'activation de la segmentation et de l'indexation des mots pour tous les champs
7. Dans la poursuite des performances d'écriture, vous pouvez définir l'index en cours d'écriture en une seule copie et ouvrir la copie une fois l'écriture terminée.
Nous rencontrons souvent des clients qui effectuent une synchronisation de données entre deux clusters ou deux index, comme la migration de données entre clusters via logstash et la reconstruction d'index entre index via l'API de réindexation. Dans ce scénario d'importation rapide de données, vous pouvez d'abord fermer la copie d'index du côté cible, car dans le scénario de migration de données, il existe déjà une copie des données d'origine dans l'index source, il n'est donc pas nécessaire de s'inquiéter de la perte de données. après avoir fermé la copie. Attendez que la migration soit terminée, puis ouvrez la copie. Dans le même temps, nous pouvons également définir le temps refresh_interval pour qu'il soit plus grand, par exemple 30 s. Le but est de réduire la génération de fichiers de segments. Et le nombre de fusions de fichiers de segment, réduisant ainsi la surcharge de performances du CPU et des E/S, et garantissant les performances d'écriture du cluster.
Ci-dessus, nous avons analysé en profondeur les principes de base et le processus d'indexation des documents du cluster ES, combinés à l'expérience d'exploitation et de maintenance et aux leçons apprises de nombreux clients majeurs de Tencent Cloud ES, et résumé 7 suggestions liées à l'optimisation des performances d'écriture. J'espère que cela pourra être utile à tous les clients de Tencent Cloud ES.