ElasticSearch - Nombre optimal de fragments par nœud
J'apprécierais que quelqu'un puisse suggérer le nombre optimal de fragments par nœud ES pour des performances optimales ou fournir un moyen recommandé pour arriver au nombre de fragments à utiliser, compte tenu du nombre de cœurs et de l'empreinte mémoire.
Il y a trois conditions à considérer avant de partager.
Situation 1) Vous souhaitez utiliser elasticsearch avec basculement et haute disponibilité. Ensuite, vous allez pour le sharding. Dans ce cas, vous devez sélectionner le nombre de fragments en fonction du nombre de nœuds [instance ES] que vous souhaitez utiliser en production.
Considérez que vous voulez donner 3 nœuds en production. Ensuite, vous devez choisir 1 fragment principal et 2 répliques pour chaque index. Si vous choisissez plus de fragments que vous n'en avez besoin.
Situation 2) Votre serveur actuel contiendra les données actuelles. Mais en raison de l'augmentation future des données dynamiques, vous pouvez vous retrouver sans espace sur le disque ou votre serveur ne peut pas gérer beaucoup de données, alors vous devez configurer plus de fragments comme 2 ou 3 fragments (selon vos besoins) pour chaque index. Mais il ne devrait pas y avoir de réplique.
Situation 3) Dans cette situation, vous la situation combinée des situations 1 et 2. vous devez alors combiner les deux configurations. Considérez vos données augmentées dynamiquement et vous avez également besoin d'une haute disponibilité et d'un basculement. Ensuite, vous configurez un index avec 2 fragments et 1 réplique. Ensuite, vous pouvez partager des données entre les nœuds et obtenir des performances optimales ..!
Remarque: Ensuite, la requête sera traitée dans chaque fragment et effectuera une réduction des résultats de tous les fragments et nous renverra le résultat. Le processus de réduction de la carte est donc un processus coûteux. Des fragments minimum nous donnent des performances optimales
Si vous n'utilisez qu'un seul nœud en production, alors un seul fragment principal est un nombre optimal de fragments pour chaque index.
J'espère que ça aide..!
Je suis en retard à la fête, mais je voulais juste souligner deux ou trois choses:
- Le nombre optimal d'éclats par index est toujours 1. Cependant, cela ne donne aucune possibilité d'échelle horizontale.
- Le nombre optimal de fragments par nœud est toujours 1. Cependant, vous ne pouvez pas redimensionner horizontalement plus que votre nombre actuel de nœuds.
Le point principal est que les fragments ont un coût inhérent à la fois à l'indexation et à l'interrogation. Chaque fragment est en fait un index Lucene distinct. Lorsque vous exécutez une requête, Elasticsearch doit exécuter cette requête sur chaque fragment, puis compiler les résultats des fragments individuels pour obtenir un résultat final à renvoyer. L'avantage du partage est que l'index peut être distribué sur les nœuds d'un cluster pour une meilleure disponibilité. En d'autres termes, c'est un compromis.
Enfin, il convient de noter que plus d'un fragment par nœud introduira des considérations d'E/S. Étant donné que chaque fragment doit être indexé et interrogé individuellement, un nœud avec 2 fragments ou plus nécessiterait 2 opérations d'E/S distinctes ou plus, qui ne peuvent pas être exécutées en même temps. Si vous avez des SSD sur vos nœuds, le coût réel de cela peut être réduit, car toutes les E/S se produisent beaucoup plus rapidement. Pourtant, c'est quelque chose dont il faut être conscient.
Cela pose donc la question de savoir pourquoi voudriez-vous avoir plus d'un fragment par nœud? La réponse à cela est l'évolutivité planifiée. Le nombre de fragments dans un index est fixe. La seule façon d'ajouter plus de fragments plus tard est de recréer l'index et de réindexer toutes les données. Selon la taille de votre index, cela peut ou non être un gros problème. Au moment de la rédaction de cet article, l'index de Stack Overflow est de 203 Go (voir: https://stackexchange.com/performance ). C'est un gros problème pour recréer toutes ces données, donc le re-partage serait un cauchemar. Si vous avez 3 nœuds et un total de 6 fragments, cela signifie que vous pouvez facilement évoluer jusqu'à 6 nœuds à un stade ultérieur sans avoir à les réaffecter.
Je viens de rentrer de la configuration du stockage de journaux pour 10 TB alors parlons de partitionnement: D
Limitations des nœuds
Source principale: Le guide définitif de elasticsearch
HEAP: 32 Go maximum :
Si le tas est inférieur à 32 Go, la JVM peut utiliser des pointeurs compressés, ce qui économise beaucoup de mémoire: 4 octets par pointeur au lieu de 8 octets.
HEAP: 50% de la mémoire du serveur au maximum . Le reste est laissé aux caches du système de fichiers (donc les serveurs de 64 Go sont un point idéal commun):
Lucene fait bon usage des caches du système de fichiers, qui sont gérés par le noyau. Sans suffisamment d'espace de cache du système de fichiers, les performances en souffriront. De plus, plus de mémoire est dédiée au tas, moins il y a de disponibilité pour tous vos autres champs utilisant des valeurs doc.
[Un index divisé en] N fragments peuvent répartir la charge sur N serveurs :
1 fragment peut utiliser toute la puissance de traitement d'un nœud (c'est comme un index indépendant). Les opérations sur les indices fragmentés sont exécutées simultanément sur tous les fragments et le résultat est agrégé.
Moins de fragments c'est mieux (l'idéal est 1 fragment) :
Les frais généraux de partage sont importants. Voir cette référence pour les chiffres https://blog.trifork.com/2014/01/07/elasticsearch-how-many-shards/
Moins de serveurs c'est mieux (l'idéal est 1 serveur (avec 1 fragment)]) :
La charge sur un index ne peut être divisée entre les nœuds que par partitionnement (un fragment suffit pour utiliser toutes les ressources sur un nœud). Plus de fragments permettent d'utiliser plus de serveurs mais plus de serveurs apportent plus de frais généraux pour l'agrégation de données ... Il n'y a pas de déjeuner gratuit.
Configuration
Utilisation: un seul gros index
Nous mettons tout dans un seul grand index et laissons elasticsearch faire tout le travail difficile relatif aux données de partitionnement. Il n'y a aucune logique dans l'application, il est donc plus facile à développer et à maintenir.
Supposons que nous prévoyons que l'index soit au maximum de 111 Go à l'avenir et que nous avons des serveurs de 50 Go (tas de 25 Go) de notre fournisseur de cloud.
Cela signifie que nous devrions avoir 5 fragments.
Remarque : La plupart des gens ont tendance à surestimer leur croissance, essayez d'être réaliste. Par exemple, cet exemple de 111 Go est déjà un GRAND index. À titre de comparaison, l'indice de stackoverflow est de 430 Go (2016) et c'est l'un des 50 meilleurs sites au monde, entièrement composé de textes écrits par des millions de personnes.
Utilisation: Index par temps
Lorsqu'il y a trop de données pour un seul index ou que cela devient trop ennuyeux à gérer, la prochaine chose est de diviser l'index par période.
L'exemple le plus extrême est celui des applications de journalisation (logstach et graylog) qui utilisent un nouvel index chaque jour.
La configuration idéale de 1 fragment unique par index est parfaitement logique dans le scénario. La période de rotation de l'index peut être ajustée, si nécessaire, pour garder l'index plus petit que le tas.
Cas spécial : Imaginons un forum Internet populaire avec des indices mensuels. 99% des demandes atteignent le dernier index. Nous devons définir plusieurs fragments (par exemple 3) pour répartir la charge sur plusieurs nœuds. (Remarque: il s'agit probablement d'une optimisation inutile. Un taux de réussite de 99% est peu probable dans le monde réel et la réplique de fragment pourrait de toute façon distribuer une partie de la charge en lecture seule).
Utilisation: Go Exascale (juste pour mémoire)
ElasticSearch est magique. C'est la base de données la plus facile à configurer en cluster et c'est l'une des rares à pouvoir évoluer vers de nombreux nœuds (à l'exclusion de Spanner ).
Il est possible d'aller exascale avec des centaines de nœuds Elasticsearch. Il doit y avoir de nombreux indices et fragments pour répartir la charge sur autant de machines et cela prend une configuration de partage appropriée (éventuellement ajustée par index).
Le dernier morceau de magie consiste à régler le routage elasticsearch pour cibler des nœuds spécifiques pour des opérations spécifiques.
Cela peut également être une bonne idée d'avoir plus d'un fragment principal par nœud, selon le cas d'utilisation. J'ai découvert que l'indexation en masse était assez lente, un seul cœur de processeur a été utilisé - nous avions donc une puissance de processeur inactive et des IO très faibles, le matériel n'était certainement pas un goulot d'étranglement. Les statistiques du pool de threads montrent que pendant l'indexation, un seul thread en bloc était actif. Nous avons beaucoup d'analyseurs et de tokenizer complexes (analyse décomposée des mots allemands). L'augmentation du nombre de fragments par nœud a entraîné l'activation d'un plus grand nombre de threads en vrac (un par fragment sur le nœud) et a considérablement amélioré la vitesse d'indexation.
Je n'ai pas encore testé cela, mais aws a un bon article sur EX meilleures pratiques . Regardez Choix des types d'instances et tests partie.
Si vous avez des données qui peuvent être divisées en éléments logiques et que vos requêtes sont généralement ciblées, c'est une bonne idée de partager en fonction de cette logique pour tirer parti du mécanisme de `` routage personnalisé ''.
Par exemple, vous disposez de données immobilières pour 50 états et interrogeriez toujours par 1 ou plusieurs états, vous créeriez 50 fragments et route en fonction du nom de l'état.
Au lieu de diffuser aveuglément tous les fragments, vous dites à Elasticsearch: "Hé! Recherchez les données sur ce fragment! Tout est là, je le promets! ". Par exemple, vous pouvez acheminer des documents en fonction de leur code_état. Ou leur Zip ou code postal. Ou tout ce qui est couramment recherché/filtré dans votre application.
Le routage garantit que tous les documents ayant la même valeur de routage seront localisés dans le même fragment, éliminant ainsi la nécessité de diffuser des recherches.
Voir ici pour plus de détails: https://www.elastic.co/blog/customizing-your-document-routing
Cela a le potentiel d'augmenter sensiblement les performances, si votre problème s'inscrit dans le créneau desservi par le routage personnalisé.