Quand commencez-vous des nœuds Elasticsearch supplémentaires?
Je suis en train d'essayer de remplacer une configuration Solr par Elasticsearch. Il s'agit d'une nouvelle configuration, qui n'a pas encore été mise en production, j'ai donc beaucoup d'espace pour jouer avec les choses et les faire fonctionner correctement.
J'ai de très, très grandes quantités de données. J'indexe des données en direct et je les conserve pendant 7 jours (en utilisant le champ _ttl). Je ne stocke aucune donnée dans l'index (et désactivé le champ _source). Je m'attends à ce que mon indice se stabilise autour de 20 milliards lignes. Je mettrai ces données dans 2-3 index nommés. Jusqu'à présent, les performances de recherche avec jusqu'à quelques milliards de lignes sont tout à fait acceptables, mais les performances d'indexation sont un problème.
Je suis un peu confus quant à la façon dont ES utilise les fragments en interne. J'ai créé deux nœuds ES, chacun avec un répertoire de données distinct, chacun avec 8 index et 1 réplique. Lorsque je regarde l'état du cluster, je ne vois qu'un fragment et une réplique pour chaque nœud. Chaque nœud ne fait-il pas fonctionner plusieurs index en interne? (La vérification de l'emplacement de stockage sur disque montre qu'il n'y a certainement qu'un seul index Lucene présent.) - Résolu, car mon paramètre d'index n'a pas été correctement récupéré dans la configuration. La création de l'index à l'aide de l'API et la spécification du nombre d'éclats et de répliques ont maintenant produit exactement ce que j'aurais pensé voir.
De plus, j'ai essayé d'exécuter plusieurs copies du même nœud ES (à partir de la même configuration), et il reconnaît qu'il existe déjà une copie en cours d'exécution et crée sa propre zone de travail. Ces nouvelles instances de nœuds semblent également n'avoir qu'un seul index sur le disque. - Maintenant que chaque nœud utilise en fait plusieurs indices, un seul nœud avec de nombreux indices est plus que suffisant pour limiter la système entier, donc ce n'est pas un problème.
Quand démarrez-vous des nœuds Elasticsearch supplémentaires, pour des performances d'indexation maximales? Dois-je avoir plusieurs nœuds exécutant chacun avec 1 réplique d'index 1, ou moins de nœuds avec des tonnes d'index? Y a-t-il quelque chose qui me manque dans ma configuration afin que les nœuds uniques fassent plus de travail?
Aussi: Existe-t-il une métrique pour savoir quand un nœud HTTP uniquement est surchargé? En ce moment, j'ai un nœud dédié à HTTP uniquement, mais à part l'utilisation du processeur, je ne peux pas dire s'il fonctionne bien ou non. Quand est-il temps de démarrer des nœuds HTTP supplémentaires et de diviser votre logiciel d'indexation pour pointer vers les différents nœuds?
Clarifions un peu la terminologie d'abord:
- Noeud : une instance Elasticsearch en cours d'exécution (un processus Java). Habituellement, chaque noeud s'exécute sur sa propre machine.
- Cluster : un ou plusieurs nœuds avec le même nom de cluster.
- Index : plus ou moins comme une base de données.
- Type : plus ou moins comme une table de base de données.
- Éclat : effectivement un indice de lucène. Chaque index est composé d'un ou plusieurs fragments. Un fragment peut être un fragment principal (ou simplement un fragment) ou une réplique .
Lorsque vous créez un index, vous pouvez spécifier le nombre de fragments et le nombre de répliques par fragment. La valeur par défaut est 5 fragments principaux et 1 réplique par fragment. Les fragments sont automatiquement répartis uniformément sur le cluster. Un fragment de réplique ne sera jamais alloué sur la même machine où se trouve le fragment principal associé.
Ce que vous voyez dans l'état du cluster est bizarre, je vous suggère de vérifier vos paramètres d'index à l'aide de get settings API . Il semble que vous n'ayez configuré qu'un seul fragment, mais de toute façon vous devriez voir plus de fragments si vous avez plus d'un index. Si vous avez besoin de plus d'aide, vous pouvez publier le résultat obtenu grâce à elasticsearch.
Le nombre de fragments et de répliques que vous utilisez dépend vraiment de vos données, de la façon dont vous y accédez et du nombre de nœuds/serveurs disponibles. Il est préférable de surallouer un peu les fragments afin de les redistribuer au cas où vous ajouteriez plus de nœuds à votre cluster, car vous ne pouvez pas (pour l'instant) modifier le nombre de fragments une fois que vous avez créé l'index. Sinon, vous pouvez toujours modifier le nombre de fragments si vous souhaitez effectuer une réindexation complète de vos données.
Chaque fragment supplémentaire a un coût puisque chaque fragment est effectivement une instance de Lucene. Le nombre maximal de fragments que vous pouvez avoir par machine dépend vraiment du matériel disponible et de vos données. Bon à savoir qu'avoir 100 index avec chacun un fragment ou un index avec 100 fragments est vraiment le même puisque vous auriez 100 instances lucene dans les deux cas.
Bien sûr, au moment de la requête, si vous souhaitez interroger un index elasticsearch unique composé de 100 fragments, elasticsearch devrait tous les interroger afin d'obtenir des résultats corrects (sauf si vous avez utilisé un routage spécifique pour vos documents pour interroger ensuite uniquement un fragment spécifique). Cela aurait un coût de performance.
Vous pouvez facilement vérifier l'état de votre cluster et de vos nœuds à l'aide de Cluster Nodes Info API grâce auquel vous pouvez vérifier de nombreuses informations utiles, tout ce dont vous avez besoin pour savoir si vos nœuds fonctionnent correctement ou non. . Encore plus facile, il existe quelques plugins pour vérifier ces informations via une interface utilisateur Nice (qui utilise en interne les API elasticsearch): paramedic and bigdesk .