As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Como escolher o número de fragmentos Depois de entender os requisitos de armazenamento, você poderá investigar a sua estratégia de indexação. Por padrão, no OpenSearch Serviço, cada índice é dividido em cinco fragmentos principais e uma réplica (total de 10 fragmentos). Esse comportamento difere do código aberto OpenSearch, cujo padrão é um fragmento primário e um fragmento de réplica. Como você não pode alterar facilmente o número de fragmentos principais para um índice existente, decida sobre a contagem de fragmentos *antes* de indexar seu primeiro documento. O objetivo geral de escolher um número de fragmentos é distribuir um índice de forma uniforme por todos os nós de dados no cluster. No entanto, esses fragmentos não devem ser muito grandes nem muito numerosos. Uma orientação geral é buscar manter o tamanho do fragmento entre 10 e 30 GiB, para workloads em que a latência de pesquisa é um dos principais objetivos de performance, e entre 30 e 50 GiB, para workloads em que há gravação intensa, como analytics de log. Fragmentos grandes podem dificultar OpenSearch a recuperação de falhas, mas como cada fragmento usa uma certa quantidade de CPU e memória, ter muitos fragmentos pequenos pode causar problemas de desempenho e erros de falta de memória. Em outras palavras, os fragmentos devem ser pequenos o suficiente para que a instância de OpenSearch serviço subjacente possa lidar com eles, mas não tão pequenos que sobrecarreguem desnecessariamente o hardware. Por exemplo, suponha que você tenha 66 GiB de dados. Você não espera que esse número aumente ao longo do tempo e deseja manter seus fragmentos em torno de 30 GiB cada um. Seu número de fragmentos, portanto, deve ser aproximadamente 66 \* 1,1/30 = 3. Você pode generalizar esse cálculo da seguinte maneira: **(Dados da origem \+ espaço para crescer) \* (1 \+ sobrecarga de indexação) / tamanho desejado do fragmento = número aproximado de fragmentos principais** Essa equação ajuda a compensar o crescimento dos dados ao longo do tempo. Se você espera que os mesmos 66 GiB de dados quadrupliquem nos próximos anos, o número aproximado de fragmentos será (66 \+ 198) \* 1,1/30 = 10. No entanto, lembre-se de que você *ainda* não tem esses 198 GiB de dados extras. Verifique se essa preparação para o futuro não cria desnecessariamente fragmentos muito pequenos que consomem enormes quantidades de CPU e memória. Nesse caso, 66 \* 1,1/10 fragmentos = 7,26 GiB por fragmento, o que consumirá recursos adicionais e está abaixo do intervalo de tamanho recomendado. Você pode considerar a middle-of-the-road abordagem mais ampla de seis fragmentos, o que deixa você com fragmentos de 12 GiB hoje e fragmentos de 48 GiB no futuro. Em seguida, novamente, você pode preferir começar com três fragmentos e reindexar seus dados quando os fragmentos ultrapassarem 50 GiB. Um problema muito menos comum envolve limitar o número de fragmentos por nó. Se você dimensionar seus fragmentos adequadamente, normalmente ficará sem espaço em disco muito antes de atingir esse limite. Por exemplo, uma instância `m6g.large.search` tem um tamanho máximo de disco de 512 GiB. Se você ficar abaixo de 80% do uso do disco e dimensionar seus fragmentos em 20 GiB, ela poderá acomodar aproximadamente 20 fragmentos. Elasticsearch 7. *x* e versões posteriores, e todas as versões de OpenSearch até 2.15, têm um limite de *1.000* fragmentos por nó. Para ajustar o máximo de fragmentos por nó, ajuste a configuração `cluster.max_shards_per_node`. Para a OpenSearch versão 2.17 e versões posteriores, o OpenSearch Service oferece suporte a 1.000 fragmentos para cada 16 GB de memória heap da JVM, até um máximo de 4.000 fragmentos por nó. Para ver um exemplo, consulte [Configurações de cluster](https://opensearch.org/docs/latest/opensearch/rest-api/cluster-settings/#request-body). Para saber mais sobre número de fragmentos, consulte [Cotas de número de fragmentos](limits.md#shard-count). Se dimensionar os fragmentos adequadamente, você quase sempre se manterá abaixo desse limite, mas também é possível considerar o número de fragmentos para cada GiB de heap Java. Em um determinado nó, não tenha mais de 25 fragmentos por GiB de heap de Java. Por exemplo, uma instância `m5.large.search` tem um heap de 4 GiB, de modo que cada nó não deva ter mais de 100 fragmentos. Nessa contagem de fragmentos, cada fragmento tem aproximadamente 5 GiB de tamanho, o que está bem abaixo da nossa recomendação.