Noeuds, Shards, Réplique dans elasticsearh


(BAKALA) #1

Bonjour,

Je viens de commencer avec elasticsearch.
Mon premier noeud est fonctionnel avec un index.
Ce que je ne comprends pas jusqu'ici c'est la notion de sharding et même de réplication propre à elasticsearch.

Dans mongodb par exemple un shard représente une partie d'un index. il faut rassembler les deux parties l'une sur noeud1-> 192.168.0.10, l'autre sur noeud2->192.168.0.11 pour constituer l'ensemble des données. Si l'on envisage une haute disponibilité des données on peut répliquer les données de noeud1 sur (noeud11->192.168.0.x, noeud12->192.168.0.x ...) et noeud2 sur (noeud21->192.168.0.x, noeud22->192.168.0.x...).

Et si noeud1 et noeud2 venaient à se saturer on peut ajouter aisément un noeud3->192.168.0.12. ( le cluster va distribuer les données sur les trois noeuds "on parle de split, de chunck, de balancing...) ainsi notre index sera reparti sur n shard répliqués ou non, ici n=3

Comment cela est possible avec elasticsearch ?
quelle est l'importance des shards et des répliques sur un noeud non distribué avec elasticsearch ?

Je suis perdu


(Sylvain Wallez) #2

Bonjour,

Comme dans MongoDB, les données d'un index sont distribuées sur les différents shards qui le composent. Mais à la différence de MongoDB, le nombre de shards est est défini à la création de l'index et ne peut pas être modifié par la suite.

Quel intérêt d'avoir plusieurs shards en configuration non distribuée ? Ça peut être utile en prévision d'une distribution future, ou bien si on sait déjà qu'il va y avoir un très grand nombre de petits documents dans l'index (un shard ne peut contenir que 2 milliards de documents).

Le fait que le nombre de shards soit non modifiable n'est pas forcément une contrainte, puisqu'on peut ensuite regrouper plusieurs index dans un alias. Cette fonctionnalité est très utilisée dans le cas de données temporelles où on va créer un nouvel index périodiquement, ce qui permet d'une part de limiter le volume de données à traiter quand on fait une recherche sur une fenêtre temporelle, et d'autre part de pouvoir très facilement "purger" les données anciennes obsolètes en supprimant les index anciens.

En espérant que ça éclaircisse les choses,
Sylvain


(BAKALA) #3

Bonjour sylvain,

Merci d'avoir pris le temps de me répondre.

donc avec elasticsearch on peut parler d'un provisionning prévisionnel qui se fait à la création de l'index. Lorsque le noeud2 viendra rejoindre le cluster existant les données de noeud1 seront reparties sur les deux noeuds.

Si noeud2 tombe ses données ne seront plus accessibles; c'est bien cela ?


(Sylvain Wallez) #4

Tout à fait : en ajoutant un noeud, Elasticsearch va équilibrer les shards sur les différents noeuds. Pour assurer la disponibilité des données en cas de crash, il faut activer la réplication.


(system) #5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.