Bonjour,
Je suis étudiant et je travaille sur les performances d' ElasticSearch.
Je cherche à dimensionner une infrastructure qui serait capable de recevoir des milliers de transactions en parallèle venant de différents clients.
La visualisation des données se ferait essentiellement grâce à des tableau de bords kibana.
L'indexation de documents représenterait 90 % de l'utilisation d'elastic et la visualisation (query) 10 %. L’infrastructure doit donc être orientée pour de l'indexation.
Après avoir parcouru divers articles, je suis arrivé à ces conclusions :
On considère que l'on a un seul node par instances.
2 ou 3 "client node" qui s'occuperont uniquement de recevoir les requêtes http. On utiliserait un système de load-balancing, pour repartir les requêtes sur ces "client nodes".
3 "master/non-data node" (On en utilise trois pour assurer le bon fonctionnement général du cluster en cas de panne d'un master node)
5/6 "data node"
Il semblerait que le nombre de shard conseillé soit de 1.5 à 3 fois le nombre de nodes (data node), donc dans le cas où on aurait 6 nodes, il faudrait utiliser entre 9 et 18 shards.
Enfin, pour la partie visualisation, on aurait 2 "client node" avec kibana installé sur chaque instance. On utiliserait là aussi un load-balancing pour répartir les requêtes sur les deux instances de kibana.
En fait c'est plutôt par l'inverse qu'on raisonne. On définit le nb de doc par shard, puis le nb de shards possibles par node, puis le nb de shards nécessaires pour nos index.
Et en fonction de ça on détermine le nombre de noeuds dont on a besoin.
Je n'ai pas bien compris cette partie là. Tu veux dire "mettre un client node elasticsearch co-localisés avec chaque instance Kibana"?
L'architecture d'un point de vue général me semble bonne (séparer master/data et clients). En tout cas, elle est faite pour effectivement envisager l'avenir.
Il faut voir concrètement si le volume à traiter en fait nécessite tout cela.
Sur ce point, je vais effectuer les calculs afin de trouver le nombre de nodes adaptés et utiliser les conseils de la vidéo.
Pour visualiser nos données, nous utilisons notre propre webapp, qui contient des graphes que l'on crée nous même à partir de requêtes sur elastic, mais aussi des Iframes qui contiennent des dashboards kibana.
Le but est donc d'avoir une ou deux instances avec des "client node" dédiées à la visualisation. Notre application de visualisation enverrait les requêtes sur ces nœuds et la génération des dashboards "appelés" par les Iframes utiliseraient les ressources de ces instances. Ainsi, si les ressources des nos instances dédiées à la visualisation venaient à être saturées, les taches d'indexation ne seraient que très peu impactées.
Notre projet consiste à installer un plugin sur des sites de e-commerce, ce plugin enverra 1 document à indexer par seconde par client connecté sur le site.
Sur des sites de e-commerce très consultés, en particulier à certaines heures, Elasticsearch recevra des milliers de documents à indexer en parallèle. Je cherche donc à dimensionner une infrastructure capable de recevoir ces documents. Voilà pourquoi, je pensais utiliser un load-balancing ainsi que 2-3 "client node" pour "réceptionner" ces documents et les diriger vers les "data-node".
Pour la visualisation, seul certains administrateurs auront accès à l'application de visualisation, un seul "client node" dédié à la visualisation avec Kibana installé est peut-être suffisant.
Merci beaucoup de votre aide, et de m'aider grâce à votre expérience, à répondre à la fameuse question "ça depend".
Ok. Un peu luxueux mais ça fait sens. A noter que le noeuds client font en fait assez peu de chose. L'intérêt de cette architecture est effectivement la capacité à couper un flux de recherche facilement. Néanmoins, couper Kibana aurait le même effet je pense.
Oui. Très certainement. Du coup, si seuls les admins ont accès à ça, ils peuvent aussi passer par les autres noeuds client je pense.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
