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 Otimização de custos

O pilar de otimização de custos do AWS Well-Architected Framework se concentra em evitar custos desnecessários e criar arquiteturas de forma otimizada. As recomendações a seguir podem ajudá-lo a atender aos princípios de design de otimização de custos e às melhores práticas arquitetônicas do Amazon Timestream for InfluxDB.

O pilar de otimização de custos foca as seguintes áreas principais:

Entendendo os requisitos e custos do seu caso de uso

Recomendamos não usar o Timestream para InfluxDB nos seguintes casos de uso:

Seleção de recursos com atenção ao custo

Os custos da instância do InfluxDB são baseados em uma taxa horária para as horas em que sua instância é executada. As instâncias representam, em média, 85% do custo geral de execução de um banco de dados AWS, portanto, o dimensionamento correto pode ter implicações de custo significativas. A melhor maneira de dimensionar corretamente as instâncias é testar o desempenho do aplicativo:

Os custos das instâncias são escalonados linearmente. O custo por hora da db.influx.2xlarge instância é o dobro do da db.influx.xlarge instância, embora também tenha o dobro da alocação de recursos. A db.influx.16xlarge instância é 16 vezes o custo por hora da db.influx.xlarge instância.

Estime o número de gravações e leituras da sua carga de trabalho para um período específico (segundo, minuto, hora ou dia). O Timestream para instâncias do InfluxDB suporta 50.000 a mais de 500.000 gravações por segundo e de 10 a 100 consultas por segundo (QPS) com base no tipo de instância. Por exemplo, db.influx.2xlarge normalmente suporta até 150.000 gravações por segundo e aproximadamente 25 QPS. Com um modelo de dados eficiente e consultas eficientes, ele pode superar esse desempenho. Se seus requisitos variarem de acordo com a hora do dia, da semana ou do mês, você pode programar o aumento e a redução da escala fazendo o seguinte:

Escalabilidade para atender às necessidades do negócio sem gastar em excesso

Para experimentação básica com o Timestream for InfluxDB, você pode usar e. db.influx.medium db.influx.large Essas instâncias são grandes o suficiente para que você tenha experiência com o Timestream for InfluxDB antes de investir em instâncias maiores.

As db.influx.large instâncias db.influx.medium e são boas para ambientes de desenvolvimento de baixo custo. No entanto, eles têm uma RAM menor (8 GiB e 16 GiB), menos v (CPUs 1 vCPU e 2 vCPUs) e desempenho de rede de até apenas 10 GB. Nem todas as cargas de trabalho são adequadas para essas classes de instância. Monitore CPUUtilization MemoryUtilization e aumente ou diminua a escala conforme necessário. Geralmente, há uma proporção consistente entre a memória e a vCPU. A classe de instância db.influx tem uma memory-to-vCPU proporção semelhante à classe de instância r7g do Amazon EC2. É altamente recomendável executar testes de end-to-end desempenho ou carga antes de começar a produção.

A modelagem eficiente de dados, a gravação em lote e as consultas otimizadas exigem menos uso de memória e computação. Quando menos recursos são necessários, você pode potencialmente usar instâncias menores.

Dimensionamento correto do armazenamento e da transferência de dados

Para armazenar dados, use as seguintes práticas recomendadas:

Para transferência de dados, recomendamos implantar seu aplicativo da mesma Região da AWS forma que sua instância de banco de dados Timestream for InfluxDB para evitar sobrecarga de rede entre regiões. Também pode haver taxas de transferência de dados. Para obter mais informações sobre transferência de dados, consulte a página de preços.