bonjour, sur un index il y a un nombre max de shard à mette ou pas . Actuellement j'ai mis 10 shard et j'ai 7 million de documents actuellement .
Sur une requête avec une aggs Terms et dedans une sous aggs SUM je trouve la réponse un peu lente pour un size de 6000 . Alors je voulais savoir si le nombre de shard et de replica avait un impact sur la vitesse ?
Pourquoi ? La question principale est là.
Regarde ces liens :
Ca t'aidera à trouver quel est le bon nombre de shards qu'il te faut. A la lecture, moins tu en as, mieux c'est. A l'écriture, plus tu en as, mieux c'est. Pour résumer dans les grosses lignes.
je trouve la réponse un peu lente pour un size de 6000
Plus tu vas augmenter size, plus tu vas perdre de temps. Surtout avec beaucoup de shards.
Peux-tu montrer un exemple de requête que tu passes pour voir de quel size on parle ici ?
du coup après avoir vu la vidéo j'ai une question !!
mon système enregistre des informations pour des sites . Est ce que je créer un index par site et je les mets dans un alias ? ou comme j'ai actuellement je mets tous le monde dans le même index !!
Ça dépend. Si il y a beaucoup de sites (notamment petits), mieux vaut les mettre dans un seul index avec un alias mais surtout du routing afin que toutes les données du site aillent vers le même shard.
avec partition sur un size de 1000, cela ne fait plus planté le serveur et sa répond plus vite
j'avait testé hier soir sans comprend mais ce midis c'est bon
par contre c'est bizarre , je demande un order par imp, dans la partie 0 j'ai une liste de résultats , mais quand je demande la partition 1 , j'obtiens une liste qui n'est pas la suite ordonné sur le nombre de imp desc.
en somme je termine la partition 0 avec imp = 10 et je repart la partition 1 avec un imp a 1000 !!!
En regardant ton example de document avec des impressions et des clicks tu peux peut etre considérer dupliquer tes donnees, j'avais un probleme similaire et dans mon cas mes cliques et impressions etaient en lecture seule (i.e je ne faisait pas de update). Un index pour mes données et un autre avec seulement les clicks et impressions un document par click, a la logstach. Du coup pour les données paginées je tapais dans le second index.
Un autre exemple avec les tags, ou j'ai un index avec tous mes tags avec un compteur et d'autres champs, plus un second index avec mes documents qui contiennent les tags, dans ce cas je faisais plus de update pour incrementer les compteurs de tags.
Tout ca pour dire que des fois dupliquer les données ca peux aider a resoudre un problem de pagination sur aggs.
L'ordre des partitions ne depend pas de l'ordre de l'aggregation par termes. Si tu demandes 100 partitions, chaque partition retourne un set de termes differents triés par le critère demandé mais la partition N+1 n'est pas la suite trié de la partition N. En résumé toutes les partitions sont triés mais pour avoir le tri complet tu dois faire un merge sort de toutes les partitions.
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.