2015-12-29 1 views
0

J'ai une configuration élastique de recherche avec 192 indices actifs allant de quelques centaines de mb à éventuellement 5gb chacun. J'ai lu que pour un cas d'utilisation de logstash avec des index 1gb, vous ne devriez utiliser que 1 fragment. La différence avec mon installation est que je vais avoir plus d'utilisateurs (estimation de jusqu'à 100) s'attendant à un temps de réponse rapide. J'ai l'intention d'avoir 1 réplique pour la fiabilité.Elasticsearch répartition des fragments pour les petits indices

Est-ce que 1 fragment par index sera toujours approprié pour mon cas d'utilisation?

+0

Si la principale chose qui vous inquiète est la performance de recherche, vous pouvez facilement ajouter ou supprimer des répliques, ne pas avoir à se soucier de la taille des fragments pour les performances de recherche sur les petits index – vizgne

Répondre

1

En un mot: oui. Le besoin de créer plusieurs fragments primaires découle de la nécessité d'isoler des documents, des comptages extrêmes (par exemple, lorsque vous êtes dans le volume de milliards de documents), ou d'améliorer le débit d'écriture (écrire des documents dans plusieurs endroits, réduisant ainsi charge individuelle).

En pratique, vous souhaitez partitionner en fonction de votre cas d'utilisation, à moins que vous ne soyez l'un de ces deux premiers scénarios (isolation ou comptage extrême).

  • Êtes-vous lourd?
  • Ecrivez-vous lourd? (Moins commun, mais cela arrive)

Si vous êtes lourd, comme c'est le cas dans la plupart des cas d'utilisation, alors avoir moins de fragments vous aidera en limitant la taille de la requête (moins d'endroits à regarder). Étant donné que vos tailles de partition sont également relativement petites (je considère que tout ce qui est inférieur à 5 Go est relativement petit), vous pouvez facilement obtenir un seul primaire et cela devrait améliorer vos performances de recherche.

Les index qui partagent les mêmes mappages, mais qui sont également minuscules ("quelques centaines de Mo"), devraient probablement être combinés si vous effectuez une recherche entre eux. Si elles sont indépendantes, alors cela ne fait vraiment aucune différence et l'isolation ressemble à une bonne pratique au détriment d'un léger gonflement de votre état de cluster (avec chaque index).

+0

Merci. Oui, je peux envisager de combiner certains des plus petits. Nous avions l'intention de les fermer pendant les mois de roulage, mais il serait peut-être préférable de les fermer en grands groupes en un seul index. –

2

Jetez un oeil à ce blog: https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index. Il a beaucoup de bons conseils pour le sharding et le dimensionnement des tessons. Cependant, la question que vous devriez vraiment vous poser est la suivante: Est-ce facile de changer? Quand il s'agit de dimensionnement et d'évolutivité, la réponse est souvent "ça dépend" - et la vraie question est: à quelle vitesse pouvez-vous reconfigurer?

Ceci pourrait être par ex. signifie que vous concevez votre application d'une manière, qui permet de ré-enrouler rapidement les données dans un nouvel index, que vous utilisez des alias pour que vous puissiez en fait changer ces choses, où se trouvent vos données (pas seulement dans Elastic, j'espère)

En construisant un système - dès le début - de sorte que vous puissiez rapidement reconstruire des indications vous permet d'expérimenter avec des tailles - et plus important encore - de les changer en fonction de vos besoins.

+0

Oui, c'est l'article qui m'a laissé cette question. J'espère construire un rapide processus de réindexation, bien que cela dépende en grande partie des ressources que je reçois. –