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á.

Pilar Eficiência de performance

O pilar de eficiência de desempenho do AWS Well-Architected Framework se concentra em como otimizar o desempenho ao ingerir ou consultar dados. A otimização do desempenho é um processo incremental e contínuo do seguinte:

O pilar de eficiência de desempenho fornece diretrizes que podem ajudar você a escolher um modelo de dados de alto desempenho. O pilar de eficiência de desempenho inclui as melhores práticas de otimização de consulta e gravação.

O pilar de eficiência de desempenho se concentra nas seguintes áreas principais:

Modelagem de dados de influxo e otimização de consultas

Projetar um esquema eficaz é crucial para otimizar o desempenho e os recursos de consulta de dados de séries temporais no InfluxDB. Comece escolhendo as tags e os campos corretos. O InfluxDB indexa as tags, portanto, o mecanismo de consulta não precisa escanear todos os registros em uma medição para localizar o valor da tag. Isso significa que consultar tags é mais eficiente do que consultar campos. Para compactar e armazenar dados, o mecanismo de armazenamento agrupa valores de campo por chave de série e, em seguida, ordena esses valores de campo por hora. Uma chave de série é definida por medição, chave e valor de tag e chave de campo. Para obter mais informações sobre design de dados, consulte a documentação do InfluxDB.

O mecanismo de armazenamento usa um formato de dados Time-Structured Merge Tree (TSM). Para obter mais informações sobre o formato de dados TSM, consulte a documentação do InfluxDB.

Imagine que você está coletando dados (timestamphost_id,region,cpu,memory,network_in_bytes,network_out_bytes,disk_io) como parte de um caso de DevOps uso. As tags, incluindo a data e hora do registro, fornecem contexto para ajudar a identificar quem, o quê, quando e onde de um registro. As tags são usadas para organizar e categorizar dados e filtrar dados como parte de uma consulta.

As region tags host_id e são etiquetas ideais para organizar e categorizar o caso de DevOps uso. Essas colunas ajudam a filtrar os dados de um determinado host ou a executar análises com base na coluna da região.

As medidas fornecem a base para realizar cálculos matemáticos (como calcular totais, médias e diferenças na taxa de variação) e análises quantitativas em seus dados. Portanto,cpu,memory, network_in_bytesnetwork_out_bytes, e disk_io capture métricas importantes relacionadas ao DevOps que estão mudando com o tempo. Você pode usar essas métricas para realizar várias análises, como calcular a CPU e a memória em diferentes hosts. Você pode usar esses valores métricos para tomar decisões baseadas em dados que ajudam a evitar interrupções na produção e a realizar o planejamento da infraestrutura.

A cardinalidade é a combinação de valores de tag exclusivos. Procure manter a cardinalidade o mais baixa possível. Se seu aplicativo exigir um identificador exclusivo para cada ponto de dados, use valores de campo em vez de valores de tag. Isso resultará em uma latência de consulta significativamente melhor. Um bom design de esquema pode evitar uma alta cardinalidade de séries, resultando em consultas com melhor desempenho. Se você notar que as leituras e gravações de dados estão diminuindo ou se quiser saber como a cardinalidade afeta o desempenho, consulte a documentação do Timestream for InfluxDB.

Se seu aplicativo emitir objetos JSON, converta-os em colunas individuais (tags ou campos) e carregue as colunas no InfluxDB. O InfluxDB foi projetado para dados de séries temporais, portanto, organizar seus dados com colunas individuais é a melhor prática para aproveitar ao máximo os recursos do serviço.

Uma única instância OSS do InfluxDB v2.7 suporta aproximadamente 20 buckets do InfluxDB que estão sendo ativamente gravados ou consultados em todas as organizações. Mais de 20 buckets podem afetar adversamente o desempenho. Existem limites em algumas opções de configuração do InfluxDB e algumas opções que você pode configurar com base no seu caso de uso. Valide a configuração com base na carga de trabalho do aplicativo durante a fase de teste. As retenções de dados são configuradas no nível do bucket, portanto, dados com diferentes requisitos de retenção de dados devem ser armazenados em diferentes buckets. Para obter mais informações sobre as opções de configuração, consulte a documentação do Timestream for InfluxDB.

Armazene dados em valores de tag ou valores de campo, não em chaves de tag, chaves de campo ou medidas. Se você criar seu esquema para armazenar dados em valores de tag e campo, suas consultas serão mais fáceis de escrever e mais eficientes. Para obter mais práticas recomendadas sobre modelagem de dados, consulte Design para desempenho.

Use as tarefas do InfluxDB para pré-agregar dados, carregar os dados em diferentes medidas ou compartimentos e gerar dados para painéis e visualizações a partir deles.

O InfluxDB OSS expõe um /metrics endpoint que retorna métricas de desempenho, recursos e uso formatadas no formato de exposição de texto simples do Prometheus. Use os modelos do InfluxDB para configurar o monitoramento e os alertas para detectar problemas de forma proativa, como alta latência de consulta, degradação da taxa de transferência de gravação ou picos de uso de recursos.

O Timestream for InfluxDB fornece armazenamento incluído no Influx IO. Selecionar o tamanho de IOPS apropriado pode acelerar significativamente a execução da consulta. Isso é especialmente útil para consultas que precisam digitalizar grandes quantidades de dados ou lidar com uma grande variedade de solicitações. Em algumas situações, uma combinação de escalar a instância e aprimorar o IOPS pode ser necessária para alcançar as melhorias de desempenho desejadas.

Recomendamos combinar os ambientes de desenvolvimento e produção (classe de instância, tipo de armazenamento, configurações). Teste as mudanças no ambiente inferior para cada versão antes de passar para a produção. Nos volumes de armazenamento incluídos no Influx IO, o Timestream for InfluxDB fornece três níveis de armazenamento pré-configurados com IOPS ideais (3.000, 12.000, 16.000) e taxa de transferência necessária para diferentes tipos de cargas de trabalho. A maioria dos casos de uso exige menos de 3.000 IOPS. Escolha 12.000 ou 16.000 somente se o teste de desempenho indicar a necessidade de alto IOPS. Para obter mais informações, consulte a seção Configuração na documentação do Timestream for InfluxDB.

Otimize gravações

Para otimizar as gravações no InfluxDB, recomendamos gravar dados em lotes de 5.000 linhas de protocolo de linha por solicitação para minimizar a sobrecarga da rede. Para um melhor desempenho, classifique as tags por chave em ordem lexicográfica antes de gravar os pontos de dados. Usar a maior precisão de tempo possível para registros de data e hora, em vez de nanossegundos, também pode melhorar o desempenho. Ativar a compactação gzip é outra forma de acelerar as gravações e reduzir a largura de banda da rede. Na configuração do plug-in de influxdb_v2 saída em seu telegraf.conf arquivo, defina a content_encoding opção comogzip. A implementação dessas otimizações pode melhorar significativamente o desempenho e a eficiência da gravação de dados no InfluxDB. Para obter mais práticas recomendadas de gravação do InfluxDB, consulte Otimizar gravações no InfluxDB.

O desempenho de gravação do InfluxDB geralmente está intimamente ligado ao IOPS disponível. Ao gravar dados, o InfluxDB precisa realizar um número significativo de operações de E/S para armazenar os dados. Quando você aumenta o IOPS, o InfluxDB pode processar mais gravações por segundo.