Elasticsearch:Avaliar especificações e capacidade de armazenamento

Precauções

Os métodos de avaliação apresentados neste tópico baseiam-se em resultados de testes reais e na experiência de usuários. Diferentes cenários podem ter requisitos distintos quanto à estrutura de dados, complexidade de consultas, volume de dados, desempenho e alterações nos dados. Este conteúdo serve apenas como referência. Recomendamos que você avalie as especificações e a capacidade de armazenamento do seu cluster Elasticsearch com base nos seus dados reais e cenários de negócio.

Avaliação de espaço de armazenamento

O espaço de armazenamento de um cluster Elasticsearch é determinado pelos seguintes fatores:

• Volume de dados de source.

• Número de shards de réplica: cada shard primário deve ter pelo menos um shard de réplica.

• Sobrecarga de indexação: na maioria dos casos, a sobrecarga de indexação é 10% maior que a dos dados de source.

  Por exemplo, índices de monitoramento usados pelo X-Pack para análise de exceções geram sobrecarga de indexação. Esses índices incluem os seguintes tipos:

  • .monitoring-es-6-*: este tipo de índice consome uma grande quantidade de espaço de armazenamento. Por padrão, o Elasticsearch retém apenas os dados de índice criados nos últimos sete dias.

  • .monitoring-kibana-6-*: o espaço consumido por este tipo de índice aumenta conforme o número de índices cresce. Por padrão, o Elasticsearch retém apenas os dados de índice criados nos últimos sete dias.

  • .watcher-history-3-*: este tipo de índice consome pouco espaço de armazenamento. Se esses índices não forem mais necessários, exclua-os manualmente.

• Sobrecarga interna do cluster Elasticsearch: operações internas, como mesclagem de segmentos e geração de logs, produzem sobrecarga de indexação. Reserve 20% do espaço de armazenamento para essa sobrecarga.

  O espaço consumido pelos logs do cluster aumenta conforme o número de consultas e envios de dados recebidos pelo cluster Elasticsearch. Os logs do cluster incluem logs de execução, logs de acesso e logs lentos. Por padrão, o Elasticsearch retém apenas os logs gerados nos últimos sete dias. Não é possível alterar esse período.

• Espaço reservado pelo sistema operacional: por padrão, o sistema operacional reserva 5% do espaço de armazenamento para processos críticos, recuperação do sistema e fragmentos de disco.

• Margem de segurança: o Elasticsearch reserva pelo menos 15% do espaço de armazenamento como margem de segurança.

Calcule o espaço de armazenamento recomendado utilizando a seguinte fórmula:

Recommended storage space of the cluster = Volume of source data × (1 + Number of replica shards) × Indexing overheads/(1 - Storage space reserved by the operating system)/(1 - Internal overheads of the cluster)/(1 - Security threshold overheads)
             = Volume of source data × (1 + Number of replica shards) × 1.7
             = Volume of source data × 3.4

Avaliação das especificações e da quantidade de nós

Nós de dados

• Número máximo de nós por cluster = Número de vCPUs por nó × 5.

• O volume máximo de dados que cada nó de um cluster Elasticsearch pode armazenar varia conforme o cenário de negócio:

  • Cenários gerais: Espaço máximo de armazenamento por nó = Tamanho da memória por nó (GiB) × 30.

  • Cenários de consulta, como aceleração ou agregação de consultas de dados: Espaço máximo de armazenamento por nó = Tamanho da memória por nó (GiB) × 10.

  • Cenários de log, como importação de dados de log ou análises offline: Espaço máximo de armazenamento por nó = Tamanho da memória por nó (GiB) × 50.

A tabela a seguir lista o número máximo de nós e o espaço máximo de armazenamento por nó para diferentes especificações.

Calcule o espaço total de armazenamento de um cluster Elasticsearch com a seguinte fórmula: Total storage space of an Elasticsearch cluster = Storage space per node × Number of nodes. Defina as especificações de cada nó com base no espaço máximo de armazenamento por nó e no número máximo de nós.

Nós mestres dedicados

Se o seu cluster Elasticsearch contiver muitos nós de dados, ative nós mestres dedicados para garantir a estabilidade do cluster.

Consulte as instruções abaixo para determinar as especificações dos nós mestres dedicados do seu cluster Elasticsearch:

• Especificações padrão: 2 vCPUs e 8 GiB de memória.

• Quando o número de nós de dados excede 10: 4 vCPUs e 16 GiB de memória.

• Quando o número de nós de dados excede 30: 8 vCPUs e 32 GiB de memória.

• Quando o número de nós de dados excede 50: 16 vCPUs e 64 GiB de memória.

Nós clientes

Ao utilizar nós clientes independentes, é possível executar a operação reduce no resultado da avaliação. Dessa forma, se ocorrer uma coleta de lixo (GC) intensa durante a fase de reduce, os nós de dados não serão afetados.

Ao ativar nós clientes, configure-os junto aos nós de dados na proporção de 1:5 e selecione especificações com proporção de 1:4 ou 1:8 entre vCPU e memória para os nós clientes. Adquira pelo menos dois nós clientes. Por exemplo, se você configurar 10 nós de dados com especificações de 8 vCPUs e 32 GiB de memória, configure 2 nós clientes com especificações de 8 vCPUs e 32 GiB de memória.

Avaliação de shards

O número de shards e o tamanho de cada um afetam a estabilidade e o desempenho de um cluster Elasticsearch. Planeje adequadamente os shards para todos os índices do cluster. Isso evita que uma quantidade excessiva de shards prejudique o desempenho ou cause desequilíbrio de carga em cenários de negócio complexos. Por exemplo, um planejamento inadequado de shards para um índice pode resultar em diferenças significativas no uso de disco e em cargas desiguais de CPU entre os nós.

A Alibaba Cloud fornece as seguintes diretrizes para o planejamento de shards. Estas orientações servem apenas como referência.

• Volume de dados armazenados em cada shard

  • Armazene no máximo 30 GiB de dados por shard. Em casos especiais, o limite pode chegar a 50 GiB por shard.

  • Em cenários de análise de logs ou que exigem índices extremamente grandes, garanta que cada shard armazene no máximo 100 GiB de dados.

• Quantidade de shards

  • Antes de alocar shards para o seu cluster Elasticsearch, avalie o volume de dados que deseja armazenar.

    • Se o volume total de dados for grande, reduza a quantidade de dados gravados para diminuir a carga de trabalho do cluster. Nesse caso, configure múltiplos shards primários para cada índice e um shard de réplica para cada shard primário.

    • Se tanto o volume total de dados quanto o volume de gravação forem pequenos, configure um shard primário por índice e um ou mais shards de réplica para cada shard primário.

    Nota

    • Por padrão, um cluster Elasticsearch V7.X ou posterior vem configurado com um shard primário por índice e um shard de réplica para cada shard primário. Clusters anteriores à versão V7.X possuem, por padrão, cinco shards primários por índice e um shard de réplica para cada shard primário.

    • Se o volume de dados a ser armazenado for inferior a 30 GiB, configure um shard primário por índice e múltiplos shards de réplica para esse shard primário, visando o balanceamento de carga. Por exemplo, se cada índice tem 20 GiB e seu cluster possui cinco nós de dados, configure um shard primário por índice e quatro shards de réplica para cada shard primário.

  • Mantenha o número de shards igual ao número de nós de dados ou a um múltiplo inteiro desse número.

  • Configure no máximo cinco shards por índice em cada nó.

  • Calcule o número total de shards para todos os índices em um único nó usando uma das fórmulas abaixo:

    • Para clusters com especificações menores: Número de shards em um único nó de dados = Tamanho da memória do nó de dados × 30.

    • Para clusters com especificações maiores: Número de shards em um único nó de dados = Tamanho da memória do nó de dados × 50.

    Nota

    • Ao calcular o número de shards, considere também o volume de dados. Se o volume for inferior a 1 TiB, utilize a fórmula para clusters com especificações menores.

    • Por padrão, o número máximo de shards em um único nó em um cluster Elasticsearch V7.X é 1.000. Evite alterar esse valor máximo. Caso precise aumentar o número de shards por nó, adicione mais nós antes de utilizar o cluster.

    • Configure os shards conforme suas necessidades de negócio. Mais shards primários geram maior sobrecarga de desempenho. Configurar um número excessivo de shards por índice pode esgotar os identificadores de arquivo (file handles), causando falhas no cluster Elasticsearch.

Para mais informações sobre avaliação de shards, consulte Como dimensionar seus shards.

Referências

• Para conhecer as especificações de nós suportadas em diferentes regiões e versões, ou para comprar um cluster Elasticsearch, acesse a página de compra.

• Consulte os resultados dos testes de estresse em clusters Elasticsearch de diferentes especificações e versões para entender o desempenho de cada especificação de nó. Para mais detalhes, visualize os tópicos no diretório Desempenho.

• Para informações sobre as diferenças entre os tipos de cluster Standard Edition e Kernel-enhanced Edition, bem como as mudanças de recursos em cada versão, consulte Recursos das versões.

• Ajuste itens como especificações dos nós, espaço de armazenamento e quantidade de nós de um cluster Elasticsearch existente com base no resultado da avaliação. Para saber como realizar essas operações e conhecer as precauções relacionadas, consulte Atualizar configuração do cluster e Reduzir configuração de um cluster.

• Especifique o número de shards primários para um índice somente no momento da criação. Após criar o índice, não é possível alterar esse número. Para saber como criar um índice, consulte Criar um índice.

• Se o volume de dados armazenados em cada shard de um índice existente ultrapassar o volume recomendado, reindexe os dados desse índice. Para mais informações, consulte Usar a API reindex para migrar dados entre clusters do Alibaba Cloud Elasticsearch.

  Nota

  A reindexação de dados garante a continuidade do serviço, mas é um processo demorado.

• Para resolver problemas de carga desequilibrada em um cluster Elasticsearch, consulte Cargas desequilibradas em um cluster.

• Para corrigir a distribuição desigual de dados quentes (hot data) entre os nós, consulte Distribuição desigual de dados quentes nos nós.

• Se você ativar o recurso Auto Indexing, utilize o gerenciamento de ciclo de vida de índice (ILM) ou um script da API do Elasticsearch para excluir índices obsoletos. Para mais informações sobre o ILM, consulte Gerenciar dados do Heartbeat com ILM.

• Exclua índices pequenos periodicamente para liberar memória heap.

Motivos para diferenças no armazenamento de índices

O tamanho de armazenamento pode variar significativamente entre índices. As seções a seguir descrevem os motivos comuns para essas diferenças e os métodos de solução de problemas.

• Configurações diferentes de analisador: o analisador ngram divide o texto em muitas combinações pequenas de caracteres, gerando muito mais tokens do que o analisador standard. Isso resulta em um índice invertido maior. Por exemplo, para os mesmos documentos, um índice que usa um analisador ngram com min_gram=1 e max_gram=4 pode ser cerca de 3,4 vezes maior do que o mesmo índice usando o analisador standard.

• Tipos de campo e configurações de mapeamento diferentes: um campo text cria um índice invertido, enquanto um campo keyword não. Configurações de mapeamento distintas afetam diretamente o uso de armazenamento.

• Número diferente de réplicas: um valor maior para o parâmetro number_of_replicas aumenta o consumo total de armazenamento.

• Configurações de compactação diferentes: a configuração best_compression utiliza o algoritmo DEFLATE. Esse algoritmo oferece uma taxa de compactação superior à do algoritmo LZ4 default, mas à custa de uma leve redução no desempenho de leitura/gravação.

Para investigar diferenças de armazenamento, execute as etapas a seguir:

• Execute o comando GET _cat/indices?v&bytes=b para visualizar o tamanho de armazenamento de cada índice.

• Execute o comando POST <index>/_disk_usage?run_expensive_tasks=true para analisar a distribuição de armazenamento no nível de campo e identificar os campos que consomem mais espaço.