Les shards
Emmanuel Bouton
Tout d'abord merci David pour le lien vers la conf de l'analyseur
français, ça m'a bien aidé ;)
Est-ce que quelqu'un pourrait m'expliquer la notion de shards ?
J'ai bien compris que c'était un moyen de fragmenter l'index, mais en
pratique ça sert à quoi exactement ? Dans quels cas doit on jouer avec
le nombre de shards d'un index ?
Merci
a+
Manu
Ludovic Levesque
les shards (et les replicas qui vont avec) peuvent servir à plusieurs
choses quand on gère un cluster complet.
Sur les replicas:
1. Le plus important étant l'aspect 'scalable' et 'distributed':
pouvoir rajouter des serveurs facilement, et être capable de gérer
quand on serveur tombe en panne
pour gérer un serveur qui ne répond plus, il faut que chaque shard ait
'au moins' un replica
2. répartir la charge en lecture, sur plusieurs noeuds
sur un serveur qui est beaucoup plus accédé en lecture qu'en écriture,
on peut imaginer avoir beaucoup plus qu'un seul replica par shard
Sur les shards:
3. minimiser la taille de chaque shard
dans certains cas, on peut préfèrer privilégier les performances de
rebalance, de backup de chaque shard, etc... et donc essayer de
minimiser la taille des shards/replicas. Au lieu d'avoir 4+4, on peut
imaginer 16+16, sur le même nombre de serveurs. Lors d'un rebalance de
shards, chaque partie est plus petite, et la répartition sur le
cluster a plus de chance d'être mieux équilibrée
4. pouvoir monter en charge plus simplement
vu qu'on ne peut pas changer le nombre de shards d'un index après sa
création, il vaut mieux 'voir grand' que l'inverse, il peut être plus
simple d'installer ne nouveaux serveurs que de réindexer toutes les
données avec un nouveau réglage, ça rejoint un peu le point 3
5. pouvoir répartir un peu les shards+replicas comme on le souhaite
avec le 'Shard allocation awareness' (
http://www.elasticsearch.org/guide/reference/modules/cluster.html ),
on peut décider d'avoir de plus petits shards pour pouvoir les
répartir dans des baies ou datacenters différents
La liste est sûrement non exhaustive, mais ça te donne quelques idées de départ.
Au final, c'est surtout en fonction de ce que tu comptes faire avec
l'index, et choisir un nombre de shards correct au départ est pas
forcément évident. Par contre, le nombre de replicas est modifiable en
mettant à jour les settings de l'index, c'est moins bloquant (ça
implique par contre des phases de rebalance). Tout dépend aussi
beaucoup du cluster actuel, du cluster prévu, et de la facilité ou non
de réindexer les données en cas de changement d'avis.
Ludo
2012/3/22 Emmanuel Bouton <got...@gmail.com>:
> --
> ---
> Vous pouvez également poster et consulter les réponses en anglais sur le groupe Elasticsearch https://groups.google.com/group/elasticsearch
>
> Si vous avez également posté votre question sur la mailing list elasti...@googlegroups.com, merci d'indiquer ici le lien vers cette discussion pour faciliter le suivi.
>
> Twitter : @ElasticsearchFR https://twitter.com/#!/ElasticsearchFR
> Site web (English) : http://www.elasticsearch.org/
da...@pilato.fr
Je dirais : "viens à Devoxx, je vais aborder ce point" ;-)
Sérieusement, un shard, c'est une partition (au même sens qu'Oracle peut partionner des tables).
Donc, lorsqu'un document arrive vers ES, on lui calcule son shard en fonction de son Id il me semble.
Donc, si tu as par exemple un index de 500 000 docs (500 Mo), et que tu fais un shard avec une réplication, tu auras un seul index au sens lucene créé contenant 500k docs pour 500 Mo de données.
Lorsque tu démarres un second noeud dans ton cluster, la règle de réplication=1 va entrainer la copie de 500k docs (500 Mo) sur le second noeud.
1er noeud : shard 1 (primaire)
2eme noeud : shard 1 (replica)
Si tu as besoin de démarrer un troisième noeud : il ne va rien se passer. ES ne peut rien faire de plus.
Si tu as créé ton index avec 2 shards (et 1 replica), tu vas avoir
1er noeud : shard 1 (primaire), shard 2 (replica)
2eme noeud : shard 1 (replica)
3eme noeud : shard 2 (primaire)
De fait, l'indexation pourra être plus intensive puisque gérée par deux machines physiques différentes (noeuds 1 et 3).
Si tu montes un 4 ème noeud, tu auras :
1er noeud : shard 1 (primaire)
2eme noeud : shard 1 (replica)
3eme noeud : shard 2 (primaire)
4eme noeud : shard 2 (replica)
Là un 5eme noeud n'apporte rien de plus.
Si tu découpes encore plus, tu pourras améliorer l'évolution de ton cluster. De plus, le temps de replication en cas de crash d'un des noeuds sera plus faible si tu as pas mal morcelé ton index. Recopier 100 Mo (5 shards) au lieu de 500 Mo (1 shard) dans mon exemple précédent.
Le côté négatif de la chose, c'est que plus tu as de shards, plus ES est obligé de lancer des requêtes simultanées sur ces shards et de faire du "map/reduce"...
La difficulté dans l'affaire est de bien comprendre l'usage que tu vas avoir de ton moteur de recherche.
Cela sera déterminant pour définir le nb de shards et le nb de replica que tu veux. A mettre aussi en face le nombre de machines dont tu disposes. Pas la peine de faire 40 shards à mon avis sur 2 machines...
Tu peux aussi envisager la montée en charge en jouant avec des alias sur des index.
Par exemple, tu créés un index par année (idx2012, idx2013, ...) et tu fais un alias général pointant vers chaque année (idx).
La recherche s'effectue sur idx mais elle est propagée aux différents index. Du coup, tu peux jouer sur les règles de réplication et shards pour chaque idx en fonction de la montée en charge.
A titre d'exemple, sur mon projet en PROD, j'ai gardé les valeurs par défaut (5 shards, 1 replica) et je tourne sur deux noeuds.
Un tout petit volume (250k docs), donc aucun pb (des recherches de l'ordre de 10 à 20 ms).
J'espère que cela répond.
@++
David.
> ---
> Vous pouvez également poster et consulter les réponses en anglais sur le groupe Elasticsearch https://groups.google.com/group/elasticsearch
>
> Si vous avez également posté votre question sur la mailing list elasti...@googlegroups.com, merci d'indiquer ici le lien vers cette discussion pour faciliter le suivi.
>
> Twitter : @ElasticsearchFR https://twitter.com/#!/ElasticsearchFR
> Site web (English) : http://www.elasticsearch.org/
--
David Pilato
http://dev.david.pilato.fr/
Twitter : @dadoonet