Perguntas frequentes sobre o Amazon Timestream

Dados de séries temporais são uma sequência de pontos de dados, como preços de ações, temperatura e uso de CPU de uma instância do Amazon EC2, registrados ao longo do tempo. Com dados de séries temporais, cada ponto de dados consiste em uma data/hora, um ou mais atributos e o evento que muda com o tempo. Esses dados são usados para obter insights sobre a performance e a integridade de uma aplicação, detectar anomalias e identificar oportunidades de otimização.

Por exemplo, a equipe de DevOps pode querer visualizar dados que medem as mudanças nas métricas de performance da infraestrutura, os fabricantes podem querer rastrear dados de sensores de IoT que medem mudanças de temperatura de um equipamento em uma instalação e os profissionais de marketing on-line podem querer analisar dados de sequência de cliques que capturam como um usuário navega em um site ao longo do tempo. Como os dados de séries temporais são gerados de várias fontes em volumes extremamente altos, eles precisam ser armazenados e analisados de forma econômica em tempo quase real para obter os principais insights de negócios.

O Amazon Timestream oferece o InfluxDB totalmente gerenciado, um dos bancos de dados de séries temporais de código aberto mais populares do mercado e o LiveAnalytics, um banco de dados de séries temporais sem servidor criado para escalar.

Sim, você pode comprar Database Savings Plans para uso do Amazon Timestream e reduzir seus custos em até 20% ao se comprometer com uma quantidade consistente de uso por um período de um ano. Informações adicionais sobre o uso elegível podem ser encontradas na página de preços dos Database Savings Plans.

Você pode começar a usar o Timestream no Console de Gerenciamento da AWS, na AWS Command Line Interface (AWS CLI) ou nos SDKs. Para obter mais informações, incluindo tutoriais e outros conteúdos de introdução, consulte o developer guide.

O Amazon Timestream para InfluxDB deve ser utilizado em casos de uso que exigem consultas de séries temporais quase em tempo real e quando você precisa de atributos do InfluxDB ou APIs de código aberto. O mecanismo Timestream existente, o Amazon Timestream para LiveAnalytics, deve ser usado quando você precisa ingerir mais que dezenas de gigabytes de dados de séries temporais por minuto e executar consultas SQL em terabytes de dados de séries temporais em segundos.

Sim. Os dois mecanismos se complementam para a ingestão de dados de séries temporais em baixa latência e em grande escala. Você pode inserir dados no Timestream para InfluxDB e usar um plug-in do Telegraf para enviar dados ao Timestream para análise de dados históricos por meio de consultas SQL.

Se você decidir migrar seus dados do Timestream para InfluxDB para o Timestream para LiveAnalytics, incorrerá em cobranças públicas pelo uso desse serviço, incluindo ingestão, armazenamento e consultas. É opcional usar o Timestream para LiveAnalytics com o Timestream para InfluxDB.

O Timestream para InfluxDB pode ser usado separadamente ou com suas workloads do Timestream para LiveAnalytics. O Timestream para InfluxDB é direcionado para aplicações quase em tempo real com tempos de resposta de um dígito em milissegundos. O Timestream para LiveAnalytics trata casos de uso que precisam ingerir gigabytes de dados em minutos e consultar terabytes de dados em segundos. Você pode combinar o Timestream para InfluxDB e o Timestream para LiveAnalytics em aplicações ou painéis.

Não. O Timestream cria dinamicamente o esquema de uma tabela com base em um conjunto de atributos e medidas dimensionais. Isso oferece uma definição de esquema flexível e incremental que pode ser ajustada a qualquer momento sem afetar a disponibilidade.

Depois que seus bancos de dados forem criados e estiverem disponíveis, você poderá recuperar as informações do endpoint no console do Timestream. Como alternativa, você também pode usar a API Describe para recuperar informações do endpoint (DescribeDatabase ao usar o Timestream para LiveAnalytics e DescribeDBInstances ao usar o Timestream para InfluxDB).

Você pode visualizar seus dados de séries temporais do Timestream e criar alertas usando o Grafana, uma ferramenta multiplataforma de análise e visualização interativa de código aberto. Para saber mais e encontrar exemplos de aplicações, consulte a documentação.

Você pode criar funções do AWS Lambda que interagem com o Timestream. Para obter informações mais detalhadas, consulte a documentação.

Você pode enviar dados de séries temporais coletados usando o Telegraf de código aberto diretamente para o Timestream usando o conector Telegraf. Para obter informações mais detalhadas, consulte a documentação.

Você pode acessar o Timestream pela Amazon Virtual Private Cloud (Amazon VPC) usando endpoints da VPC. Os endpoints da Amazon VPC são fáceis de configurar e oferecem conectividade confiável com as APIs do Timestream sem exigir o gateway da internet ou a instância NAT.

O AWS CloudFormation simplifica o provisionamento e o gerenciamento mediante a disponibilização de modelos CloudFormation para provisionar serviços ou aplicações de modo rápido e confiável. O CloudFormation fornece suporte abrangente para o Timestream, oferecendo modelos para a criação de bancos de dados (no Timestream para LiveAnalytics e no Timestream para InfluxDB). Os modelos estão atualizados com o último anúncio do Timestream para InfluxDB e oferecem flexibilidade e facilidade de uso aos clientes do Timestream.

O Amazon Timestream para LiveAnalytics é um banco de dados de séries temporais rápido, escalável e com tecnologia sem servidor, criado para workloads de grande escala. Ele não tem servidor e automaticamente ajusta a capacidade e a performance para que você não precise gerenciar a infraestrutura subjacente. Sua arquitetura totalmente desassociada permite que você ingira trilhões de pontos de dados e execute milhões de consultas por dia.

O mecanismo de consulta adaptável do Timestream para LiveAnalytics permite que você acesse e analise dados recentes e históricos juntos, sem precisar especificar sua localização. Ele tem funções de análise de séries temporais integradas, ajudando você a identificar tendências e padrões nos seus dados quase em tempo real.

O Timestream para LiveAnalytics foi projetado para coletar, armazenar e processar dados de séries temporais. Sua arquitetura sem servidor oferece suporte a serviços totalmente desacoplados de ingestão de dados, armazenamento e processamento de consulta que podem ser escalados de forma independente, permitindo uma escala virtualmente infinita para as necessidades da sua aplicação. Em vez de predefinir o esquema no momento da criação da tabela, o esquema de uma tabela do Timestream é criado dinamicamente com base nos atributos dos dados de séries temporais recebidos, permitindo uma definição flexível e incremental do esquema.

Para armazenamento de dados, o Timestream para LiveAnalytics particiona os dados por tempo e atributos, acelerando o acesso aos dados usando um índice criado especificamente. Os atributos de seus dados, como o nome da medida ou a chave de particionamento escolhida, desempenham um papel fundamental no particionamento eficaz e na recuperação eficiente dos dados. Além disso, o Timestream para LiveAnalytics automatiza o gerenciamento do ciclo de vida dos dados oferecendo um armazenamento na memória para dados recentes e um armazenamento magnético para dados históricos, dando suporte a regras configuráveis para mover automaticamente os dados do armazenamento de memória para o armazenamento magnético quando atingirem uma certa idade.

O Timestream para LiveAnalytics também simplifica o acesso aos dados por meio de seu mecanismo de consulta adaptável criado especificamente, que pode acessar e combinar dados de forma transparente em todas as camadas de armazenamento sem precisar especificar a localização dos dados, para que possa obter insights de seus dados de forma rápida e fácil usando SQL. Por fim, o Timestream funciona perfeitamente com seus serviços preferidos de coleta de dados, visualização, análise e machine learning, facilitando a inclusão do Timestream em suas soluções de séries temporais.

O Timestream para LiveAnalytics oferece disponibilidade de 99,99%. Para obter mais informações, consulte o contrato de nível de serviço (SLA).

Com o Timestream para LiveAnalytics, você paga somente pelo que usa. Você é cobrado separadamente por gravações, dados armazenados e dados digitalizados por consultas. O Timestream escala automaticamente a capacidade de gravação, armazenamento e consultas com base no uso. Você pode definir a política de retenção de dados para cada tabela e optar por armazenar dados em um armazenamento na memória ou magnético. Para obter preços detalhados, consulte a página de preços.

Sim, o Timestream para LiveAnalytics oferece uma avaliação gratuita de um mês para todas as novas contas. O uso da avaliação gratuita é limitado a 50 GB de ingestão, 100 GB de armazenamento magnético, 750 GB/hora de armazenamento de memória e 750 GB de dados digitalizados.

Você é cobrado de acordo com o preço padrão do Timestream para LiveAnalytics pelo uso além do que a avaliação gratuita oferece. Detalhes adicionais estão na página de preços.

Para ver a disponibilidade atual da região, consulte a página de preços.

O Timestream para LiveAnalytics oferece latências quase em tempo real para ingestão de dados. O armazenamento de memória incorporado do Timestream para LiveAnalytics é otimizado para consultas pontuais rápidas, e o armazenamento magnético é otimizado para aceitar consultas analíticas rápidas. Com o Timestream para LiveAnalytics, você pode executar consultas que analisam dezenas de gigabytes de dados de séries temporais do armazenamento de memória em milissegundos e consultas analíticas que analisam terabytes de dados de séries temporais do armazenamento magnético em segundos. Consultas agendadas melhoram ainda mais a performance das consultas calculando e armazenando agregações, pacotes cumulativos e outras análises em tempo real usadas para alimentar painéis operacionais, relatórios comerciais, aplicações e sistemas de monitoramento de dispositivos acessados com frequência.

Você pode armazenar exabytes de dados em uma única tabela. À medida que seus dados crescem com o tempo, o Timestream para LiveAnalytics usa a arquitetura distribuída e grandes quantidades de paralelismo para processar volumes maiores de dados, mantendo as latências de consulta quase inalteradas.

A arquitetura sem servidor do Timestream oferece suporte a sistemas de ingestão de dados, armazenamento e processamento de consultas totalmente dissociados que podem ser escalados de forma independente. O Timestream para LiveAnalytics monitora continuamente os requisitos de ingestão, armazenamento e taxa de consulta da aplicação para escalar instantaneamente sem qualquer tempo de inatividade da aplicação.

Para ver os limites e cotas atuais, consulte a documentação.

Você pode coletar dados de séries temporais de dispositivos conectados, sistemas de TI e equipamentos industriais e gravá-los no Timestream para LiveAnalytics. É possível enviar dados para o Timestream para LiveAnalytics diretamente da aplicação usando os SDKs da AWS ou dos serviços de coleta de dados, como AWS IoT Core, Amazon Managed Service for Apache Flink ou Telegraf. Para obter mais informações, consulte a documentação.

Dados de chegada tardia são dados que têm um registro de data e hora no passado e estão fora do limite de retenção do armazenamento de memória. Dados futuros são dados que têm um registro de data e hora no futuro. O Timestream permite que você armazene e acesse os dois tipos.

Para armazenar dados de chegada tardia, basta gravar os dados no Timestream para LiveAnalytics e o serviço determinará automaticamente se eles serão gravados no armazenamento de memória ou no armazenamento magnético, com base no registro de data e hora dos dados e no período de retenção de dados configurado para os armazenamentos de memória ou magnético. Para armazenar dados com mais de 15 minutos no futuro, modele seus dados como registro de várias medidas e represente a data/hora no futuro como medida dentro do registro.

Usando o carregamento em lotes, você pode ingerir arquivos CSV armazenados no Amazon Simple Storage Service (Amazon S3) no Timestream para LiveAnalytics. É possível usar o carregamento em lotes para preencher dados que não são imediatamente necessários para análise. Você pode criar tarefas de carregamento em lotes usando o Console de Gerenciamento da AWS, a AWS CLI e os AWS SDKs. Para obter mais informações, consulte a documentação.

Você pode coletar dados de seus dispositivos de IoT e armazenar esses dados no Timestream para LiveAnalytics usando as ações de regras do AWS IoT Core. Para obter informações mais detalhadas, consulte a documentação.

Você pode usar o Apache Flink para transferir seus dados de séries temporais do Amazon Kinesis diretamente para o Timestream para LiveAnalytics. Para obter informações mais detalhadas, consulte a documentação.

Você pode usar o Apache Flink para enviar seus dados de séries temporais do Amazon Managed Streaming for Apache Kafka (Amazon MSK) diretamente para o Timestream para LiveAnalytics. Para obter informações mais detalhadas, consulte a documentação.

O Timestream organiza e armazena dados de séries temporais em partições. O particionamento dos dados é determinado pelo serviço com base nos atributos dos dados. Atributos como timestamp e measure_name ou chaves de partição definidas pelo cliente desempenham um papel fundamental na decisão das partições. Consulte o blog do Werner Vogels para obter mais detalhes. Se você quiser otimizar a performance de consulta para melhor atender às suas necessidades específicas, recomendamos o uso de chaves de partição definidas pelo cliente. Usando o Timestream, você pode automatizar o gerenciamento do ciclo de vida dos dados simplesmente configurando políticas de retenção de dados para mover automaticamente os dados do armazenamento de memória para o armazenamento magnético quando atingirem a idade configurada.

O armazenamento de memória do Timestream para LiveAnalytics é um armazenamento otimizado para gravação que aceita e desduplica os dados de séries temporais recebidos. O armazenamento de memória também é otimizado para consultas de um ponto no tempo sensíveis à latência.

O armazenamento magnético do Timestream para LiveAnalytics é um armazenamento otimizado para leitura criado para executar consultas analíticas rápidas capazes de digitalizar centenas de terabytes de dados. O armazenamento magnético também é otimizado para consultas analíticas rápidas que digitalizam centenas de terabytes de dados.

Você pode definir o período de retenção para os armazenamentos de memória e magnético. Os padrões são 12 horas e dez anos, respectivamente. Como a idade dos dados, determinada pela data/hora no registro, excede o período de retenção configurado do armazenamento de memória, o Timestream para LiveAnalytics classifica automaticamente os dados no armazenamento magnético. Da mesma forma, se a idade dos dados exceder o período de retenção configurado do armazenamento magnético, o serviço excluirá automaticamente os dados.

O Timestream para LiveAnalytics garante a durabilidade de seus dados ao replicar automaticamente dados de memória e armazenamento magnético em diferentes zonas de disponibilidade dentro de uma única região. Todos os dados são gravados em disco antes de confirmar que a solicitação de gravação foi concluída.

Você pode usar SQL para consultar seus dados de séries temporais armazenados no Amazon Timestream. Também é possível usar funções de análise de séries temporais para interpolação, regressão e suavização usando SQL. Para obter mais informações, consulte a documentação. O mecanismo de consulta adaptável do Timestream permite que você acesse dados em todos os níveis de armazenamento usando uma única instrução SQL. Ele acessa e combina dados de forma transparente em todos os níveis de armazenamento sem exigir que você especifique o local dos dados. 

As consultas agendadas do Timestream para LiveAnalytics oferecem uma solução totalmente gerenciada, sem servidor e escalável para calcular e armazenar agregações, pacotes cumulativos e outras análises em tempo real usadas para alimentar painéis operacionais, relatórios comerciais, aplicações e sistemas de monitoramento de dispositivos acessados com frequência.

Com consultas agendadas, você simplesmente define as consultas analíticas em tempo real que calculam agregações, pacotes cumulativos e outras análises em tempo real dos dados recebidos, e o Amazon Timestream executa de forma periódica e automática essas consultas e grava seguramente os resultados da consulta em uma tabela separada. Em seguida, você pode direcionar seus painéis, relatórios, aplicações e sistemas de monitoramento para simplesmente consultar as tabelas de destino em vez de consultar as tabelas de origem consideravelmente maiores que contêm os dados de séries temporais recebidos. Isso leva a reduções de performance e custo em uma ordem de magnitude, porque as tabelas de destino contêm muito menos dados do que as tabelas de origem, oferecendo acesso e armazenamento de dados mais rápidos e de menor custo.

Você pode usar drivers JDBC e ODBC para conectar o Timestream para LiveAnalytics às suas ferramentas de business intelligence e outras aplicações preferenciais. Consulte a documentação do JDBC e ODBC para obter detalhes adicionais.

Você pode visualizar e analisar dados de séries temporais no Timestream para LiveAnalytics usando o Amazon QuickSight e o Grafana. Você também pode usar o QuickSight para suas necessidades de machine learning.

Você pode criar painéis avançados e interativos para seus dados de séries temporais usando o QuickSight. Para obter mais informações, consulte a documentação.

Você pode usar os cadernos do Amazon SageMaker para integrar seus modelos de ML com o Timestream para LiveAnalytics. Para obter mais informações, consulte a documentação.

Os dados serão sempre criptografados, quer estejam em repouso ou em trânsito. O Timestream para LiveAnalytics permite que você especifique uma chave gerenciada pelo cliente do AWS Key Management Service (AWS KMS) para criptografar dados no armazenamento magnético.

O Timestream para LiveAnalytics é compatível com ISO (9001, 27001, 27017 e 27018), PCI DSS, FedRAMP (Moderado) e Health Information Trust (HITRUST) Alliance Common Security Framework (CSF). Também é elegível para a HIPAA e está no escopo dos relatórios SOC 1, SOC 2 e SOC 3 da AWS.

Você tem duas opções de backup disponíveis para seus recursos do Timestream: sob demanda e agendados. Os backups sob demanda são únicos e podem ser iniciados no console do Timestream ou usando o AWS Backup. Os backups sob demanda são úteis quando você deseja criar um backup antes de fazer uma alteração na tabela, o que pode exigir que você reverta as alterações. Os backups agendados são recorrentes e você pode configurá-lo usando as políticas do AWS Backup nas frequências desejadas (por exemplo, 12 horas, um dia, uma semana etc.). Os backups agendados são úteis quando você quer criar backups contínuos para atender às suas metas de proteção de dados.

O primeiro backup, sob demanda ou programado, da tabela é um backup completo e cada backup subsequente da mesma tabela é incremental, copiando somente os dados que foram alterados desde o último backup. 

O backup e as restaurações são cobrados com base no tamanho do armazenamento de backup da tabela selecionada, medido em GB por mês. As cobranças serão mostradas em Backup na sua fatura da AWS e incluirão custos de armazenamento de backup, transferências de dados, restaurações e exclusões antecipadas. Como os backups são de natureza incremental, o tamanho do armazenamento do backup subsequente da tabela é o tamanho da quantidade de dados alterados desde o último backup. Consulte preços do AWS Backup para obter detalhes adicionais.

Para começar, você precisa habilitar o AWS Backup para proteger os recursos do Timestream para LiveAnalytics (essa é uma ação única). Depois de habilitado, navegue até o Console de Gerenciamento da AWS ou use a CLI ou o SDK do AWS Backup para criar backups sob demanda ou agendados de seus dados e copiar esses backups entre contas e regiões. Você pode configurar o gerenciamento do ciclo de vida do backup com base nas suas necessidades de proteção de dados. Para obter mais informações, consulte a documentação da criação de um backup. 

Você pode restaurar suas tabelas do Timestream para LiveAnalytics por meio do Console de Gerenciamento da AWS ou usando a CLI ou o SDK do AWS Backup. Selecione a ID do ponto de recuperação para o recurso que você quiser restaurar e forneça as entradas necessárias, como nome do banco de dados de destino, nome da nova tabela e propriedades de retenção, para iniciar o processo de restauração. Após a restauração bem-sucedida, você poderá acessar os dados. Quando você tenta restaurar o backup incremental mais recente da sua tabela, todos os dados da tabela são restaurados. Para obter mais informações, consulte a documentação.

Amazon Timestream para InfluxDB é um novo mecanismo de banco de dados de séries temporais que facilita às equipes de desenvolvimento de aplicações e DevOps a execução de bancos de dados InfluxDB na AWS para aplicações de séries temporais em tempo real usando APIs de código aberto. Com o Timestream para InfluxDB, é fácil configurar, operar e escalar workloads de séries temporais que podem responder a consultas com respostas de um dígito de milissegundos.

O Timestream para InfluxDB oferece suporte à versão 2.7 de código aberto do InfluxDB. 

Você deve usar o Timestream para InfluxDB se estiver autogerenciando o InfluxDB, quiser usar APIs de séries temporais de código aberto ou estiver criando aplicações de séries temporais em tempo real que exigem respostas de consulta de um dígito de milissegundos. Com o Timestream para InfluxDB, você obtém o benefício das APIs de código aberto e de um amplo conjunto de agentes de código aberto do Telegraf para coletar dados de séries temporais. Você não precisa gerenciar tarefas complexas e demoradas, como instalação, upgrades, armazenamento, replicação para alta disponibilidade e backups do InfluxDB.

O Timestream para InfluxDB fornece um SLA de 99,9% de disponibilidade quando implantado com uma configuração multi-AZ e disponibilidade de 99,5% para uma configuração single-AZ.

O Timestream para InfluxDB foi desenvolvido para casos de uso de séries temporais quase em tempo real. Dependendo das configurações da instância e das características das workloads, você pode esperar uma latência de gravação para leitura de aproximadamente um segundo com latência de consulta de milissegundos de um dígito.

Para migrar para o Timestream para InfluxDB de uma instância autogerenciada do InfluxDB, você pode simplesmente restaurar um backup de um banco de dados existente do InfluxDB em uma instância do Timestream para InfluxDB com alguns minutos de tempo de inatividade. Você pode reconfigurar seus agentes de coleta de dados, como agentes Telegraf de código aberto, para atingir o endpoint do InfluxDB gerenciado pelo Timestream para InfluxDB. As tecnologias de painel, como a interface do usuário do InfluxDB, o Grafana auto-hospedado ou o Amazon Managed Grafana, continuarão funcionando configurando-as para usar o endpoint do Timestream para InfluxDB sem nenhuma outra alteração de código.

Para migrar do Timestream para LiveAnalytics para o Timestream para InfluxDB, você pode exportar os dados do Timestream para LiveAnalytics para o Amazon S3, fazer as modificações necessárias nos arquivos CSV exportados e carregá-los no Timestream para InfluxDB.

Uma instância de banco de dadospode ser considerada como um ambiente de banco de dados na nuvem com os recursos de computação e armazenamento especificados. Você pode criar e excluir instâncias de banco de dados, definir e refinar atributos de infraestrutura de suas instâncias e controlar o acesso e a segurança por meio do Console de Gerenciamento da AWS, pelas APIs do Timestream para InfluxDB e pela AWS CLI. Você pode executar uma ou mais instâncias de banco de dados e cada instância pode oferecer suporte a um ou mais bancos de dados (buckets) ou organizações, dependendo das características da workload e da configuração da instância.

As instâncias de banco de dados são simples de criar usando o Console de Gerenciamento da AWS, as APIs do Timestream para InfluxDB ou a AWS CLI. Para iniciar uma instância de banco de dados usando o Console de Gerenciamento da AWS, escolha os bancos de dados InfluxDB e selecione o botão Create InfluxDB Database no painel. A partir daí, você pode especificar os parâmetros para sua instância de banco de dados, incluindo tipo de instância, tipo e quantidade de armazenamento, credenciais de usuário principal e muito mais.

Como alternativa, é possível criar a instância de banco de dados usando a API CreateDBInstance ou o comando create-db-instance.

Quando sua instância de banco de dados estiver disponível, você poderá recuperar o endpoint dela por meio da descrição da instância de banco de dados no Console de Gerenciamento da AWS, na API getDBInstance ou no comando get-db-instance. Usando esse endpoint e seu token de acesso, você pode usar as APIs do InfluxDB para enviar solicitações de gravação e leitura, bem como gerenciar o mecanismo usando sua ferramenta de banco de dados ou linguagem de programação favorita. Você também pode acessar a interface do usuário do InfluxDB do seu navegador usando o mesmo endpoint. Para permitir solicitações de rede na instância de banco de dados em execução, é necessário autorizar o acesso ou habilitar o acesso de IP público.

Por padrão, você pode ter até um total de 40 instâncias do Timestream para InfluxDB.

Você paga apenas pelo que usa e não há taxas mínimas ou de configuração. Você é cobrado com base em:

• Horas da instância do banco de dados: com base na classe (por exemplo, db.influx.large e db.influx.4xlarge) da instância de banco de dados consumida. As horas parciais da instância do banco de dados consumidas são cobradas em incrementos de um segundo, com uma cobrança mínima de dez minutos após uma alteração de estado faturável, como criação, inicialização ou modificação da classe de instância de banco de dados.
• Armazenamento (por GB/mês): capacidade de armazenamento que você provisionou para a instância de banco de dados. Caso escale a capacidade de armazenamento provisionada no mês, sua fatura será proporcional.
• Transferência de dados: transferência de dados da internet que entram e saem da instância de banco de dados.

Para obter informações sobre preços do InfluxDB, acesse a página de preços.

A cobrança de uma instância de banco de dados é iniciada a partir do momento em que a instância fica disponível. A cobrança continua até que a instância de banco de dados seja encerrada, o que pode ocorrer após sua exclusão ou caso ocorra falha na instância.

As horas da instância de banco de dados são cobradas por cada hora em que a instância está sendo executada em um estado disponível. Se você não quiser mais ser cobrado pela instância de banco de dados, deverá interrompê-la ou excluí-la para evitar cobrança por horas adicionais. As horas parciais da instância do banco de dados consumidas são cobradas em incrementos de um segundo, com uma cobrança mínima de dez minutos após uma alteração de estado faturável, como criação, inicialização ou modificação da classe de instância de banco de dados.

Enquanto sua instância de banco de dados estiver parada, você será cobrado pelo armazenamento provisionado, mas não pelas horas da instância.

Se você especificar que a instância de banco de dados deve ser uma implantação multi-AZ, a cobrança será feita de acordo com o preço multi-AZ publicado na página de preços do Timestream para InfluxDB. A cobrança multi-AZ é baseada no seguinte:

• Horas da instância do banco de dados multi-AZ: com base na classe (por exemplo, db.influx.large e db.influx.4xlarge) da instância de banco de dados consumida. De mesma forma que nas implantações padrão em um única zona de disponibilidade, as horas de instância parciais de banco de dados consumidas são cobradas em incrementos de um segundo, com uma cobrança mínima de dez minutos após uma alteração de status faturável, como criar, iniciar ou modificar a classe da instância de banco de dados. Se você converter a implantação da instância de banco de dados de padrão para multi-AZ dentro do período de uma hora, ambas as taxas aplicáveis por aquela hora serão cobradas.
• Armazenamento provisionado (para instância de banco de dados multi-AZ): se você converter a implantação de padrão para multi-AZ em um período de uma hora, a taxa de armazenamento aplicável mais alta para aquela hora será cobrada.
• Transferência de dados: você não será cobrado pela transferência de dados resultante da replicação de dados entre primário e standby. A transferência de dados da internet para dentro e para fora da instância de banco de dados terá o mesmo valor cobrado pela implantação padrão.

Salvo indicação em contrário, nossos preços excluem impostos e taxas aplicáveis, incluindo o IVA e o imposto de vendas. Para clientes com endereço de cobrança no Japão, o uso dos serviços da AWS está sujeito ao imposto sobre consumo japonês. 

• Sua fatura do cluster de réplicas de leitura do Timestream para InfluxDB é calculada por instância dentro do cluster, de acordo com os preços listados na página de preços do Timestream para InfluxDB. A estrutura de cobrança consiste em quatro componentes principais:
  As horas de nós do cluster são cobradas com base na classe de instância selecionada (como db.influx.large ou db.influx.4xlarge). Faturamos em incrementos de um segundo com uma cobrança mínima de dez minutos após qualquer alteração de status faturável, incluindo criação, inicialização ou modificações na classe da instância. Se você converter entre tipos de cluster em um uma hora, será cobrado pelas duas taxas aplicáveis durante esse período.
• Para armazenamento, você será cobrado com base na sua capacidade provisionada. Ao converter entre tipos de implantação (cluster, padrão ou banco de dados multi-AZ) em uma hora, aplicamos a maior das taxas de armazenamento aplicáveis para essa hora.
• Com relação à transferência de dados, você não pagará pela replicação de dados entre suas instâncias primária e de réplica. No entanto, a transferência de dados da internet para dentro e para fora do seu cluster de banco de dados segue os mesmos preços das implantações padrão.
• A funcionalidade de réplica de leitura é fornecida por meio de um complemento licenciado que é criado e vendido pela InfluxData e será ativado por meio do AWS Marketplace. Essa licença opera em um modelo de pagamento conforme o uso, com cobranças baseadas nas horas da instância, de acordo com o número de vCPUs em sua classe de instância configurada.
  

Para selecionar a classe de instância de banco de dados inicial e a capacidade de armazenamento, você deverá avaliar as necessidades de computação, memória e armazenamento da sua aplicação. Para obter informações sobre as classes de instância de banco de dados disponíveis, consulte o Guia do usuário do Timestream para InfluxDB.

O armazenamento com IOPS incluído do Timestream para InfluxDB é uma opção de armazenamento baseado em SSD e projetada para oferecer performance de E/S rápida, previsível e consistente. Com esse tipo de armazenamento do Timestream para InfluxDB, você tem três níveis para escolher, desde pequenas workloads até aquelas otimizadas em grande escala e de alta performance. Você só especifica o tamanho do volume alocado para o nível que melhor atende às suas necessidades. O armazenamento com IOPS incluído do Timestream para InfluxDB é otimizado para workloads de bancos de dados transacionais (OLTP) com uso intenso de E/S. Para obter mais detalhes, consulte o Timestream for InfluxDB User Guide.

Escolha o tipo de armazenamento mais adequado para a sua workload.

• Workloads OLTP de alta performance: armazenamento do Timestream para InfluxDB com a inclusão de IOPS.

Por padrão, o Timestream para InfluxDB escolhe os parâmetros de configuração ideais para a instância de banco de dados levando em consideração a classe e a capacidade de armazenamento da instância. No entanto, se quiser alterá-los, poderá fazer isso usando o Console de Gerenciamento da AWS, as APIs do Timestream para InfluxDB ou a AWS CLI. Leve em consideração que a alteração dos parâmetros de configuração dos valores recomendados pode ter efeitos indesejados, que variam de uma queda de performance até falhas de sistema. A alteração só deve ser feita por usuários avançados que desejem assumir esses riscos.

No lançamento, forneceremos um conjunto limitado de parâmetros que poderão ser modificados por você, incluindo: flux-log-enabled, log-level, metrics-disable, no-tasks, query-simultaneity, query-queue-size e tracing-type. Essa lista pode aumentar com o tempo com base nos requisitos do cliente.

Um grupo de parâmetros de banco de dados age como contêiner para valores de configuração de mecanismo que podem ser aplicados a uma ou mais instâncias de banco de dados. Se você criar uma instância de banco de dados sem especificar um grupo de parâmetros de banco de dados, um grupo padrão será usado. Esse grupo padrão contém padrões de mecanismo e padrões de sistema do Timestream para InfluxDB otimizados para a instância de banco de dados que você está executando.

No entanto, se você quiser que sua instância de banco de dados seja executada com valores de configuração de mecanismo personalizados, basta criar um novo grupo de parâmetros de banco de dados, alterar os parâmetros desejados e modificar a instância de banco de dados para usar o novo grupo. 

Ao criar ou modificar a instância de banco de dados para ser executada como implantação multi-AZ, o Timestream para InfluxDB automaticamente provisiona e mantém uma réplica standby simultânea em uma zona de disponibilidade diferente. As atualizações para a instância de banco de dados são replicadas de forma síncrona nas zonas de disponibilidade para standby a fim de manter ambas sincronizadas e proteger as atualizações de banco de dados mais recentes contra falhas de instância de banco de dados. 

Durante determinados tipos de manutenção planejada, ou no caso de falha da instância de banco de dados ou da zona de disponibilidade, o Timestream para InfluxDB realizará o failover automaticamente para a réplica standby para que você possa retomar as gravações e leituras do banco de dados assim que a réplica standby for promovida. Como o registro de nome para a instância de banco de dados permanece o mesmo, a aplicação pode retomar as operações do banco de dados sem a necessidade de intervenção administrativa manual.

Com implantações multi-AZ, a replicação é transparente. Você não interagirá diretamente com a réplica standby e ela não poderá ser usada para atender ao tráfego de leitura.

Zonas de disponibilidade são locais distintos em uma região que são projetados para serem isolados de falhas em outras zonas. Cada zona de disponibilidade opera em sua própria infraestrutura fisicamente distinta e independente e é projetada para ser altamente confiável. Pontos comuns de falhas, como geradores e equipamentos de refrigeração, não são compartilhados pelas zonas de disponibilidade. Além disso, elas são fisicamente separadas, de modo que até desastres extremamente incomuns, como incêndios, tornados ou inundações, afetariam apenas uma única zona de disponibilidade. As zonas de disponibilidade dentro da mesma região beneficiam-se de conectividade de rede de baixa latência.

Ao executar uma instância de banco de dados como implantação multi-AZ, o primário atende às gravações e leituras de banco de dados. Além disso, o Timestream for InfluxDB providencia e mantém um standby em segundo plano, que é uma réplica atualizada do primário. O standby é promovido em situações de failover. Após um failover, o standby se torna primário e aceita as operações de banco de dados. Você não interage diretamente com o standby (por exemplo, operações de leitura) em nenhum momento antes da promoção.

Os principais benefícios de executar a instância de banco de dados como implantação multi-AZ são a durabilidade e a disponibilidade aprimoradas do banco de dados. A disponibilidade e tolerância a falhas mais abrangentes oferecidas por implantações Multi-AZ as tornam a melhor opção para ambientes de produção.

A execução da instância de banco de dados como implantação multi-AZ protege os dados caso ocorra, inesperadamente, uma falha de componentes de instância de banco de dados ou uma perda de disponibilidade em uma zona de disponibilidade.

Por exemplo, se um volume de armazenamento da instância primária falhar, o Timestream para InfluxDB automaticamente iniciará um failover para a instância standby, onde todas as atualizações de seu banco de dados estão intactas. Isso fornece uma resiliência de dados adicional relativa às implantações padrão em uma única zona de disponibilidade, em que uma operação de restauração iniciada por usuário seria necessária e atualizações feitas após o último momento restaurável (geralmente dentro dos últimos cinco minutos) não estariam disponíveis.

Você também se beneficiará da disponibilidade aprimorada do banco de dados ao executar sua instância de banco de dados como uma implantação multi-AZ. Se ocorrer uma falha de zona de disponibilidade ou de instância de banco de dados, o impacto em sua disponibilidade estará limitado ao tempo que o failover automático leva para ser concluído. Os benefícios de disponibilidade de multi-AZ também se estendem à manutenção planejada. Outro benefício decorrente da execução da instância de banco de dados como implantação multi-AZ é que o failover de instância é automático e não exige qualquer administração. 

Talvez você observe latências elevadas relacionadas a uma implantação padrão de instância de banco de dados em uma única zona de disponibilidade, resultantes da replicação de dados simultânea realizada em seu nome.

Não, um standby multi-AZ não pode atender a solicitações de leitura. Implantações Multi-AZ são projetadas para fornecer disponibilidade e resiliência de banco de dados aprimoradas e não benefícios de escalabilidade de leitura. Sendo assim, o recurso utiliza replicação simultânea entre principal e em espera. Nossa implementação garante que primário e standby estejam constantemente sincronizados, mas impede o uso do standby nas operações de leitura ou gravação.

Para criar uma implantação de instância de banco de dados multi-AZ, basta clicar na opção Create a Standby Instance para a implantação multi-AZ ao iniciar uma instância de banco de dados com o Console de Gerenciamento da AWS. Como alternativa, se você estiver utilizando as APIs do Timestream para InfluxDB, poderá chamar a API CreateDBInstance e configurar o parâmetro multi-AZ com o valor True.
Você também pode modificar uma de suas instâncias existentes e definir o tipo de implantação como multi-AZ.

O Timestream for InfluxDB detecta e se recupera automaticamente das situações de falha mais comuns nas implantações multi-AZ para que você possa retomar as operações do banco de dados o mais rápido possível, sem intervenção administrativa. O Timestream para InfluxDB executa automaticamente um failover em qualquer um destes casos:

• Perda de disponibilidade na zona de disponibilidade principal
• Perda de conectividade de rede para principal
• Falha de unidade computacional na principal
• Falha de armazenamento na principal

Note: as implantações multi-AZ do Timestream para InfluxDB não executam failover automaticamente em resposta a operações do banco de dados, como consultas de longa execução, bloqueios ou erros de dano ao banco de dados.

O failover é automaticamente controlado pelo Timestream para InfluxDB para que você possa retomar as operações do banco de dados o mais rápido possível e sem intervenção administrativa. Ao ocorrer um failover, o Timestream para InfluxDB troca o registro de nome canônico (CNAME) da instância de banco de dados para indicar o standby, que em troca é promovido e se torna o novo primário. Encorajamos você a seguir as melhores práticas e implementar novas tentativas de conexão do banco de dados na camada da aplicação.

Os failovers, conforme definidos pelo intervalo entre a detecção da falha no primário e a retomada das transações no standby, geralmente são concluídos alguns minutos. O tempo de failover também pode ser afetado pela necessidade de recuperação de transações grandes e não confirmadas, pelo tamanho do índice e por outros fatores. O uso de tipos de instância adequadamente grandes é recomendado com multi-AZ para obter melhores resultados. A AWS também recomenda o uso do armazenamento com IOPS incluído do Timestream para InfluxDB com instâncias multi-AZ para uma performance de throughput rápida, previsível e consistente.

O Timestream para InfluxDB executará o failover automaticamente e sem intervenção do usuário em diversas condições de falha. No momento, você não pode iniciar manualmente um failover forçado de sua instância de banco de dados do Timestream para InfluxDB.

Com implantações multi-AZ, basta definir o parâmetro multi-AZ como verdadeiro. A criação de standby, replicação simultânea e failover é controlada automaticamente. Isso significa que não é possível selecionar a zona de disponibilidade em que standby é implantado ou alterar o número de standbys disponíveis (o Timestream para InfluxDB provisiona um standby dedicado por instância de banco de dados principal). O standby também não pode ser configurado para aceitar atividades de leitura do banco de dados.

Sim, o nó standby é automaticamente provisionado em outra zona de disponibilidade da mesma região do nó primário da instância de banco de dados.

Sim, é possível visualizar o local do seu nó primário atual utilizando o Console de Gerenciamento da AWS ou a API DescribeDBInstances.

As zonas de disponibilidade são projetadas para fornecer conectividade de rede de baixa latência para outras zonas de disponibilidade na mesma região. Além disso, você tem a opção de criar sua aplicação e outros recursos da AWS com redundância em diversas zonas de disponibilidade, de modo que sua aplicação seja resistente no caso de uma falha na zona de disponibilidade. As implantações multi-AZ tratam essa necessidade para a camada de banco de dados sem administração de sua parte.

Um cluster de réplicas de leitura do Timestream para InfluxDB oferece maior disponibilidade e escalabilidade de leitura para seu banco de dados. Quando você cria um cluster, o Timestream para InfluxDB provisiona e mantém automaticamente pelo menos uma réplica legível assíncrona em uma zona de disponibilidade diferente. As atualizações do seu nó primário são replicadas de forma assíncrona para essas réplicas de leitura, permitindo que você distribua sua workload de consulta em vários nós.

O cluster oferece suporte ao failover automático durante a manutenção planejada ou no caso improvável de uma falha no nó ou na zona de disponibilidade. Quando ocorre um failover, as aplicações podem continuar operando sem intervenção manual, uma vez que os endpoints de gravação e leitura mantêm os mesmos registros de nomes. No entanto, é importante observar que, durante o período de recuperação, enquanto restauramos o nó com falha e o restabelecemos como réplica de leitura, as aplicações que usam os endpoints de nó de réplica para leitura ficarão temporariamente indisponíveis.

Em um cluster de réplicas de leitura, o nó primário lida com todas as gravações e leituras do banco de dados e gerencia as configurações e funções administrativas específicas do mecanismo. Além disso, o Timestream para InfluxDB provisiona e mantém automaticamente uma réplica de leitura que permanece atualizada com o nó primário. A réplica de leitura serve a dois propósitos principais: ela amplia a capacidade de leitura aceitando solicitações de leitura adicionais e pode ser promovida à primária durante cenários de failover. Durante um evento de failover, quando a réplica de leitura é promovida para primária, ela assume todas as operações do banco de dados. Quando o nó que falhou anteriormente se torna operacional novamente, ele se junta novamente ao cluster como réplica de leitura, mantendo a resiliência do cluster.

Os clusters de réplicas de leitura oferecem três vantagens principais: escalabilidade aprimorada, maior disponibilidade e otimização de workloads. A maior escalabilidade vem da sua capacidade de distribuir workloads de leitura em vários nós do cluster, o que a torna particularmente valiosa para aplicações em que os requisitos de leitura superam significativamente as operações de gravação.

Quando configurados com o failover ativado, os clusters de réplicas de leitura oferecem maior disponibilidade por meio de recursos de failover mais rápidos. Como todos os nós do cluster permanecem ativos, você pode promover uma réplica para primária sem esperar pela inicialização do nó, minimizando o tempo de inatividade durante cenários de failover.

Além disso, os clusters de réplicas de leitura permitem um gerenciamento eficiente de workloads. Você pode dedicar seu nó primário para lidar com consultas simples e rápidas, normalmente usadas para painéis, alarmes e notificações em tempo real, enquanto direciona consultas analíticas mais complexas para suas réplicas de leitura. Essa separação garante a performance ideal para diferentes tipos de workloads.

O processo replicador demonstrou um impacto insignificante na performance, com efeito mínimo no consumo de CPU ou memória. No entanto, é importante observar que o atraso na replicação, que é o tempo entre o momento em que um registro é aceito no primário e o momento em que ele se torna disponível nas réplicas de leitura, pode variar dependendo do nível de carga dos nós da réplica.

O Timestream para InfluxDB publica uma métrica do CloudWatch chamada “ReplicaLag” que ajuda você a monitorar o estado de sincronização de suas réplicas de leitura. Essa métrica, medida em milissegundos, rastreia a distância entre as réplicas e o nó primário. A latência da replicação pode ser afetada pelos níveis de carga do banco de dados; portanto, recomendamos que os clientes monitorem ativamente essa métrica para garantir que suas réplicas de leitura mantenham níveis de sincronização aceitáveis para o caso de uso.

Para configurar um cluster de réplicas de leitura no Timestream para InfluxDB, comece fazendo login no Console de Gerenciamento da AWS e navegando até o console do Amazon Timestream. Escolha "Create InfluxDB database" na seção InfluxDB Databases. Ao definir as configurações de implantação, selecione "DB Cluster with Read Replicas". Você precisará ativar uma assinatura por meio do AWS Marketplace, que exige a permissão AWSMarketplaceManageSubscriptions ou AWSMarketplaceFullAccess. Depois de confirmar sua assinatura, forneça detalhes básicos de configuração e selecione as classes de nós e de armazenamento apropriadas que se aplicarão a todos os nós do cluster.

Não, em um cluster de réplica de leitura, só pode haver um nó primário que processa as operações de gravação a qualquer momento. O nó primário atende a todas as solicitações de gravação e, ao mesmo tempo, gerencia as leituras do banco de dados, as configurações específicas do mecanismo e as funções administrativas. As réplicas de leitura são mantidas atualizadas com esse nó primário e só podem aceitar solicitações de leitura. Embora você possa promover uma réplica de leitura para se tornar primária durante cenários de failover, a arquitetura do cluster mantém um modelo de gravação única para garantir a consistência de dados.

Para clusters de réplica de leitura, você pode ativar ou desativar o atributo de failover durante a criação ou modificação do cluster. Quando ativado, o gerenciamento de réplicas, replicação e processos de failover é tratado automaticamente pelo Timestream para InfluxDB. Você não pode selecionar zonas de disponibilidade específicas para suas réplicas, e o Timestream para InfluxDB mantém pelo menos uma réplica de leitura por cluster. As réplicas de leitura aceitam ativamente solicitações de leitura para ajudar a distribuir a workload.

O Timestream para InfluxDB detecta e se recupera automaticamente de cenários de falha comuns em implantações de cluster de réplicas de leitura, permitindo que você retome as operações do banco de dados rapidamente sem intervenção administrativa. O sistema executa automaticamente um failover em uma réplica de leitura no caso de qualquer uma das seguintes situações:

• Perda de disponibilidade na zona de disponibilidade do nó primário
• Perda de conectividade de rede com o nó primário
• Falha na unidade de computação no nó primário
• Falha de armazenamento no nó primário

Nota: os clusters de réplicas de leitura do Timestream para InfluxDB não falham automaticamente em resposta às operações do banco de dados, como consultas de longa duração, bloqueios ou erros de dano ao banco de dados. Lembre-se de que o failover automático só ocorrerá se você tiver habilitado especificamente esse atributo para seu cluster de réplicas de leitura durante a configuração ou por meio da modificação do cluster.

O failover em um cluster de réplicas de leitura é tratado automaticamente pelo Timestream para InfluxDB quando o atributo está ativado, permitindo que as operações do banco de dados sejam retomadas rapidamente sem intervenção administrativa. Durante o failover, o Timestream para InfluxDB atualiza o registro de nome canônico (CNAME) do banco de dados para apontar para a réplica de leitura, que é então promovida para se tornar a nova primária. Recomendamos implementar a lógica de nova tentativa de conexão do banco de dados em sua camada de aplicação como uma prática recomendada.

Como os nós em um cluster de réplicas de leitura estão ativos, o tempo de failover será estável, independentemente das características da workload. Normalmente, os failovers são concluídos em alguns minutos, desde a detecção da falha primária até a retomada das transações na réplica promovida. Para uma performance ideal, recomendamos usar tipos de nós de tamanho adequado e o armazenamento com IOPS incluído do Timestream para InfluxDB.

Quando o failover estiver habilitado, o Timestream para InfluxDB tratará automaticamente o failover sob várias condições de falha. Atualmente, não há suporte para a inicialização manual de failover forçado nos clusters de réplicas de leitura do Timestream para InfluxDB.

Sim, sua réplica de leitura é automaticamente provisionada em uma zona de disponibilidade diferente da mesma região do nó primário.

Sim, você pode visualizar a localização de seus nós primário e de réplica de leitura no Console de Gerenciamento da AWS ou usando a API GetDBInstance.

As zonas de disponibilidade são projetadas para fornecer conectividade de rede de baixa latência para outras zonas de disponibilidade na mesma região. Portanto, o impacto na latência deve ser mínimo. No entanto, recomendamos arquitetar sua aplicação e outros recursos da AWS com redundância em várias zonas de disponibilidade para máxima resiliência. Os clusters de réplica de leitura aceitam essa arquitetura naturalmente, já que você pode distribuir suas workloads de leitura entre nós em diferentes zonas de disponibilidade e, quando o failover estiver habilitado, sua aplicação poderá continuar operando mesmo que uma zona de disponibilidade fique indisponível.