Choix du nombre de partitions

Une fois que vous avez déterminé vos exigences de stockage, vous pouvez examiner votre stratégie d'indexation. Par défaut, dans OpenSearch Service, chaque index est divisé en cinq partitions principales et une réplique (10 partitions au total). Ce comportement est différent de celui de l'open source OpenSearch, qui utilise par défaut une partition principale et une partition de réplique. Comme vous ne pouvez pas modifier aisément le nombre de partitions principales pour un index existant, vous devez décider du nombre de partitions avant d'indexer votre premier document.

L'objectif général du choix d'un nombre de partitions est de répartir un index de manière uniforme sur tous les nœuds de données du cluster. Toutefois, ces partitions ne doivent pas être trop grandes, ni trop nombreuses. En règle général, la taille des partitions doit être comprise entre 10 et 30 Gio pour les charges de travail où la latence de recherche est un objectif de performance clé, et entre 30 et 50 Gio pour les charges de travail lourdes en écriture, telles que l'analyse des journaux.

Les grandes partitions peuvent compliquer la restauration après une panne, mais comme chaque partition utilise une certaine quantité de mémoire, le fait d'CPUavoir trop de petites partitions peut entraîner des problèmes de performances et des erreurs d'insuffisance de mémoire. OpenSearch En d'autres termes, les partitions doivent être suffisamment petites pour que l'instance de OpenSearch service sous-jacente puisse les gérer, mais pas au point de surcharger inutilement le matériel.

Par exemple, supposons que vous disposez de 66 Gio de données. Vous ne prévoyez pas que ce nombre augmente au fil du temps, et vous voulez maintenir vos partitions autour de 30 Gio chacune. Le nombre de partitions doit donc être d'environ 66 * 1,1/30 = 3. Vous pouvez généraliser ce calcul comme suit :

(Données source + marge de croissance) * (1 + surcharge d'indexation) / taille de partition souhaitée = Nombre approximatif de partitions principales

Cette équation permet de compenser la croissance du volume de données au fil du temps. Si vous vous attendez à ce que ces 66 Gio de données quadruplent au cours de l'année suivante, le nombre approximatif de partitions est de (66 + 198) * 1,1/30 = 10. Gardez toutefois à l'esprit que vous ne disposez pas encore de ces 198 Gio de données supplémentaires. Assurez-vous que cette préparation pour le futur ne crée pas inutilement de minuscules fragments qui consomment d'énormes quantités de CPU mémoire dans le présent. Dans ce cas, 66 * 1,1/10 partitions = 7,26 Gio par partition, ce qui consomme des ressources supplémentaires et se situe au-dessous de la plage de tailles recommandées. Vous pourriez envisager l' middle-of-the-roadapproche de six partitions, ce qui vous laisse avec des partitions de 12 Go aujourd'hui et des partitions de 48 Go dans le futur. Là encore, vous préférerez peut-être commencer avec trois partitions et réindexer vos données lorsque les partitions dépasseront 50 Gio.

Un problème beaucoup moins fréquent consiste à limiter le nombre de partitions par nœud. Si vous dimensionnez vos partitions de manière appropriée, vous manquez généralement d'espace disque longtemps avant d'atteindre cette limite. Par exemple, une instance m6g.large.search a une taille de disque maximale de 512 Go. Si vous restez en dessous de 80 % d'utilisation du disque et que vous dimensionnez vos partitions à 20 Go, il peut accueillir environ 20 partitions. Elasticsearch 7. x et versions ultérieures, ainsi que toutes les versions de OpenSearch, ont une limite de 1 000 partitions par nœud. Pour régler le nombre maximal de partitions par nœud, configurez le paramètre cluster.max_shards_per_node. Pour obtenir un exemple, consultez Paramètres du cluster.

Le dimensionnement approprié des partitions vous permet de rester presque toujours en dessous de cette limite, mais vous pouvez également prendre en compte le nombre de partitions pour chaque Go de segments de mémoire Java. Sur un nœud donné, ne dépassez pas 25 partitions par Gio de segments de mémoire Java. Par exemple, une instance m5.large.search présente un segment de mémoire de 4 Gio, de sorte que chaque nœud ne devrait pas avoir plus de 100 partitions. Avec un tel nombre de partitions, chacune d'elles a une taille d'environ 5 Go, ce qui est bien inférieur à notre recommandation.