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 ?
merci
bonne journée
Actuellement j'ai mis 10 shard
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 ?
j'ai mis 10 comme j'aurai pu mettre 15 ou 5 lol
get /myindex/_search
{
"size":0,
"query":{
"bool": {
"must": [
{
"match": {
"idsite": 41
}
}
]
}
},
"aggs":{
"listekw":{
"terms": {
"field": "idkeyword.keyword",
"size": 10000
},
"aggs": {
"imp": {
"sum": {
"field": "impressions"
}
},
"click":
{
"sum": {
"field": "click"
}
}
}
}
}
}alors le size 10000 explose le serveur mais à 6000 je passe 
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.
ok merci et pour revenir sur ma requête pour sortons les mots unique , c'est peut être pas la bonne méthode car sur une aggs on peut pas paginer ?
j'ai testé pais j'ai pas compris , on indique un nombre de partition ?
si on met "num_partitions": 20 et size 1000 par exemple et donc dans chaque partition elastic répartis le nombre de réponse de manière auto ?
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 !!!
{
"size":0,
"query":{
"bool": {
"must": [
{
"match": {
"idsite": 41
}
}
]
}
},
"aggs":{
"listekw":{
"terms": {
"field": "idkeyword.keyword",
"include": {
"partition": 1,
"num_partitions": 100
},
"order": {
"imp": "desc"
},
"size": 10000
},
"aggs": {
"imp": {
"sum": {
"field": "impressions"
}
},
"click":
{
"sum": {
"field": "click"
}
}
}
}
}
}Bonjour,
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.
c'est bien ce que j'avait remarqué que les partitions ne se suivait pas ^^ , le merge le le fait côté code ou je le demande à Elastic ?
Côté client, pour Elasticsearch toutes les partitions sont independantes, il n'y a donc pas moyen de faire le merge dans le server.
du coup quel est la bonne solution quand on veut afficher un listing d'information avec des agrégation dedans ?
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
© 2020. All Rights Reserved - Elasticsearch
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.