# Como funciona o faturamento no Aurora DSQL Com o Amazon Aurora DSQL, você paga apenas pelo que utiliza, sem custos iniciais. Esta seção explica como o Aurora DSQL mede a atividade do seu banco de dados e a converte em cobranças na sua fatura da AWS. Para os preços atuais por região, consulte a [página Preço do Aurora DSQL](https://aws.amazon.com/rds/aurora/dsql/pricing/). **Topics** + [Como funciona a medição](#billing-how-metering-works) + [Explicação da medição dos componentes de DPU](#billing-dpu-components) + [Faturamento multirregional](#billing-multiregion-write-dpu) + [Monitoramento do uso de DPU com o CloudWatch](#billing-cloudwatch-monitoring) + [Uso de EXPLAIN ANALYZE VERBOSE para conscientização sobre custos](#billing-explain-analyze) + [Práticas recomendadas para estimativa de custos](#billing-best-practices) ## Como funciona a medição Diferentemente dos bancos de dados tradicionais, que cobram pela capacidade provisionada, o Aurora DSQL cobra apenas pelo trabalho efetivamente realizado. O Aurora DSQL mede dois componentes principais: a atividade do banco de dados, medida em Unidades de Processamento Distribuído (DPUs), e o armazenamento, medido em GiB-mês. As DPUs medem quanto trabalho o sistema realiza para executar sua workload SQL e são compostas por três elementos para clusters de região única: DPUs de computação, DPUs de leitura e DPUs de gravação. Os clusters multirregionais incluem um componente adicional de DPU de gravação multirregional. Consulte detalhes em [Faturamento multirregional](#billing-multiregion-write-dpu). A tabela a seguir resume os componentes que o Aurora DSQL utiliza para medir a atividade do banco de dados. Na sua fatura, você verá apenas dois itens: um para armazenamento e outro para DPU, que corresponde à soma de todos os componentes individuais. | Unidade de medição | Tipo de atividade | Medição | | --- | --- | --- | | DPU de computação | Processamento de consulta | Tempo de CPU | | DPU de leitura | Leitura de dados do banco de dados | Bytes lidos do armazenamento | | DPU de gravação | Gravação de dados no banco de dados | Bytes gravados no armazenamento | | Armazenamento | Armazenamento de tabela | GiB-mês | ## Explicação da medição dos componentes de DPU Para cada transação, o Aurora DSQL calcula o total de DPU como a soma de três componentes: DPU de computação, DPU de leitura e DPU de gravação. As seções a seguir explicam como o Aurora DSQL mede cada componente. ``` Total DPU = ComputeDPU + ReadDPU + WriteDPU ``` ### ComputeDPU As DPUs de computação são medidas com base no tempo total de processamento gasto na execução da sua consulta, incluindo junções, funções, agregações, ordenação e planejamento da consulta. Como partes da sua consulta podem ser processadas em paralelo, a DPU de computação reflete a soma de todo o tempo de processamento, e não o tempo de relógio da execução da consulta. A fórmula a seguir resume como calcular as DPUs de computação: ``` ComputeDPU = Total Compute time (in seconds) ``` ### WriteDPU Para cada transação, o Aurora DSQL mede as DPUs de gravação pelo total de bytes gravados no armazenamento. As DPUs de gravação incluem o total de dados gravados na tabela base, bem como em quaisquer índices secundários. O Aurora DSQL fatura cada linha gravada na tabela base e nos índices secundários com menos de 128 bytes como se tivesse 128 bytes. O Aurora DSQL fatura uma transação de gravação que grava menos de 1.024 bytes como se tivesse gravado 1.024 bytes. **nota** As operações de gravação também geram cobranças de ReadDPU, porque o Aurora DSQL lê o índice de chave primária para verificar exclusividade antes de gravar. As fórmulas a seguir mostram as etapas para calcular as DPUs de gravação: **Etapa 1: calcular bytes gravados** ``` Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written ``` **Etapa 2: calcular WriteDPU** ``` WriteDPU = max(Bytes Written, 1024) × 0.00004883 ``` ### ReadDPU Para cada transação, o Aurora DSQL mede as DPUs de leitura pelo total de bytes lidos do armazenamento. As DPUs de leitura incluem dados lidos da tabela base, bem como de quaisquer índices secundários. **Mínimo por partição:** o Aurora DSQL mede bytes lidos por partição de armazenamento, não por linha. Se uma solicitação de leitura para uma partição de armazenamento retornar menos de 128 bytes, o Aurora DSQL arredondará para 128 bytes. Por exemplo, se a consulta lê de 4 partições: 200 bytes de uma partição e 50 bytes de cada uma das outras três, as três leituras de 50 bytes são arredondadas para 128 bytes cada, resultando em um total faturado de 200 \+ 128 \+ 128 \+ 128 = 584 bytes. **Mínimo por transação:** o Aurora DSQL fatura uma transação de leitura que lê menos de 2.048 bytes no total como se tivesse lido 2.048 bytes. As fórmulas a seguir mostram as etapas para calcular as DPUs de leitura: **Etapa 1: calcular bytes lidos** ``` Bytes Read = # of rows read × size of each row ``` **nota** Os bytes efetivamente lidos dependem de como os dados estão distribuídos entre as partições de armazenamento, pois o mínimo de 128 bytes por partição é aplicado por partição. Se todos os tamanhos de linha estiverem acima de 128 bytes, será possível simplesmente multiplicar o número de linhas lidas pelo tamanho de cada linha. **Etapa 2: calcular ReadDPU** ``` ReadDPU = max(Bytes Read, 2048) × 0.00000183105 ``` ### Exemplos de faturamento Os exemplos a seguir demonstram como o Aurora DSQL calcula DPUs para operações comuns. Os valores de custo nesses exemplos utilizam o preço da região us-east-1. Consulte preços em outras regiões na [página Preço do Aurora DSQL](https://aws.amazon.com/rds/aurora/dsql/pricing/). #### Exemplo: consulta pontual simples (leitura) Este exemplo demonstra um cálculo de ReadDPU para uma consulta pontual em que o mínimo por transação se aplica. **Esquema:** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes ``` **Consulta:** ``` SELECT * FROM orders WHERE customer_id = 'cust-12345'; ``` **Cenário:** a consulta retorna 5 linhas, cada uma com aproximadamente 100 bytes. Supondo que todas as linhas estejam em uma única partição de armazenamento, o total de bytes lidos é 5 × 100 = 500 bytes. Como 500 bytes excede o mínimo de 128 bytes por partição, nenhum mínimo por partição se aplica. **Calcular ReadDPU:** ``` ReadDPU = max(500, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375 ``` O mínimo por transação de 2.048 bytes se aplica, já que 500 < 2.048. **Custo total da transação:** Supondo que o tempo de execução da consulta seja de 3 ms (0,003 segundos): ``` ComputeDPU: 0.003 ReadDPU: 0.00375 WriteDPU: 0.0 ------------------- Total DPU: 0.00675 ``` #### Exemplo: varredura de intervalo com filtro (leitura) **Esquema:** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes -- Table contains 100 orders for customer 'cust-12345' ``` **Consulta:** ``` SELECT * FROM orders WHERE customer_id = 'cust-12345' AND total_amount > 500.00; ``` **Cenário:** a consulta faz a varredura de 100 linhas para o cliente “cust-12345”, mas o filtro `total_amount > 500.00` reduz o resultado para apenas 10 linhas retornadas. O Aurora DSQL fatura todas as 100 linhas da varredura. Supondo que todas as linhas estejam em uma única partição de armazenamento, o total de bytes lidos é 100 × 100 = 10.000 bytes. **Calcular ReadDPU:** ``` ReadDPU = max(10000, 2048) × 0.00000183105 = 10000 × 0.00000183105 = 0.01831 ``` Como 10.000 bytes excede o mínimo de 2.048 bytes por transação, os bytes efetivamente lidos são utilizados. **Custo total da transação:** Supondo que o tempo de execução da consulta seja de 8 ms (0,008 segundos): ``` ComputeDPU: 0.008 ReadDPU: 0.01831 WriteDPU: 0.0 ------------------- Total DPU: 0.02631 ``` **Importante** Para minimizar custos de ReadDPU, projete consultas e índices para fazer a varredura apenas das linhas necessárias. Neste exemplo, adicionar um índice em `(customer_id, total_amount)` pode permitir que a consulta faça a varredura de menos linhas. #### Exemplo: inserção única (leitura e gravação) **Esquema:** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes ``` **Consulta:** ``` INSERT INTO orders (customer_id, total_amount, status) VALUES ('cust-67890', 150.00, 'pending'); ``` **Cenário:** inserir 1 linha, aproximadamente 100 bytes. **Cálculo de WriteDPU:** *Etapa 1: calcular bytes gravados:* ``` 1 row × max(100 bytes, 128 bytes) = 1 × 128 = 128 bytes ``` *Etapa 2: calcular WriteDPU:* ``` WriteDPU = max(128, 1024) × 0.00004883 = 1024 × 0.00004883 = 0.05 ``` O mínimo por transação de 1.024 bytes se aplica, já que 128 < 1.024. **ReadDPU (verificação de chave primária):** O Aurora DSQL lê o índice de chave primária para verificar a exclusividade antes de gravar. Isso gera a cobrança mínima de leitura por transação. ``` ReadDPU = 0.00375 (transaction minimum) ``` **Custo total da transação:** Supondo que o tempo de execução da consulta seja de 8 ms (0,008 segundos): ``` ComputeDPU: 0.008 ReadDPU: 0.00375 WriteDPU: 0.05 ------------------- Total DPU: 0.06175 ``` #### Exemplo: inserção em massa (leitura e gravação) **Esquema:** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes ``` **Consulta:** ``` INSERT INTO orders (customer_id, total_amount, status) VALUES ('cust-001', 100.00, 'pending'), ('cust-002', 150.00, 'pending'), ... -- 100 rows total ('cust-100', 200.00, 'pending'); ``` **Cenário:** inserir 100 linhas, cada uma com aproximadamente 100 bytes. **Cálculo de WriteDPU:** *Etapa 1: calcular bytes gravados:* ``` 100 rows × max(100 bytes, 128 bytes) = 100 × 128 = 12,800 bytes ``` *Etapa 2: calcular WriteDPU:* ``` WriteDPU = max(12800, 1024) × 0.00004883 = 12800 × 0.00004883 = 0.625 ``` **ReadDPU (verificações de chave primária):** O Aurora DSQL lê o índice de chave primária de cada linha para verificar a exclusividade. Supondo que todas as 100 consultas de chave estejam em uma única partição de armazenamento, o total de bytes lidos é 100 × 16 bytes = 1.600 bytes: ``` ReadDPU = max(1600, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375 ``` O mínimo por transação de 2.048 bytes se aplica, já que 1.600 < 2.048. **Custo total da transação:** Supondo que o tempo de execução da consulta seja de 80 ms (0,08 segundos): ``` ComputeDPU: 0.08 ReadDPU: 0.00375 WriteDPU: 0.625 ------------------- Total DPU: 0.70875 ``` ## Faturamento multirregional Os clusters multirregionais geram um componente adicional de DPU de gravação multirregional, além das DPUs padrão de computação, leitura e gravação. Esta seção se aplica apenas a clusters multirregionais. Clusters de região única não geram essa cobrança. As DPUs de gravação multirregional medem o total de bytes gravados na região emparelhada. Como o Aurora DSQL replica de forma síncrona os dados gravados na região emparelhada, o valor da DPU de gravação multirregional é equivalente ao da DPU de gravação. O Aurora DSQL cobra essa DPU na região de origem da gravação, não na região emparelhada. ``` MultiRegionWriteDPU = WriteDPU ``` ## Monitoramento do uso de DPU com o CloudWatch O Aurora DSQL publica métricas de uso no Amazon CloudWatch, permitindo monitorar o consumo quase em tempo real. ### Métricas de DPU disponíveis **Métricas de DPU** | métrica do cloudwatch | Descrição | Dimensão | | --- | --- | --- | | WriteDPU | Componente de uso de gravação | ClusterId | | ReadDPU | Componente de uso de leitura | ClusterId | | ComputeDPU | Componente de processamento de consultas | ClusterId | | MultiRegionWriteDPU | Replicação multirregional (apenas clusters multirregionais) | ClusterId | | TotalDPU | Soma de todos os componentes de DPU | ClusterId | ### Visualização de métricas de DPU **Como visualizar métricas de DPU no CloudWatch** 1. [Abra o console do CloudWatch](https://console.aws.amazon.com/cloudwatch). 1. Acesse **Métricas**, **AuroraDSQL** e **ClusterId**. 1. Selecione o cluster e as métricas de DPU que deseja monitorar. **dica** Use a estatística **Soma** para métricas de DPU para ver o uso total ao longo de um período. Adicione o rótulo **LAST** para ver o valor mais recente. ### Métricas adicionais de observabilidade Consulte uma lista completa dos recursos de monitoramento e métricas do Aurora DSQL em [Monitoramento e registro em log do Aurora DSQL](monitoring-overview.md). **Métricas de observabilidade** | Métrica | Descrição | | --- | --- | | ClusterStorageSize | Tamanho atual do armazenamento em bytes | | TotalTransactions | Total de transações executadas | | ReadOnlyTransactions | Transações somente leitura executadas | | QueryTimeouts | Consultas que excederam o limite de tempo | | OccConflicts | Transações anuladas devido a conflitos de OCC | | BytesWritten | Bytes brutos gravados no armazenamento | | BytesRead | Bytes brutos lidos do armazenamento | ## Uso de EXPLAIN ANALYZE VERBOSE para conscientização sobre custos O Aurora DSQL estende `EXPLAIN ANALYZE VERBOSE` para incluir uma estimativa de uso de DPU por instrução ao final da saída. Isso oferece visibilidade imediata do custo da consulta, ajudando você a identificar os fatores de custo da workload, ajustar a performance da consulta e prever melhor o uso dos recursos. **nota** É necessário usar `EXPLAIN ANALYZE VERBOSE` (com VERBOSE) para visualizar estimativas de DPU. Um `EXPLAIN ANALYZE` simples, sem VERBOSE, não exibe informações de DPU. ### Exemplo 1: consulta SELECT ``` EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table; ``` ``` QUERY PLAN ---------------------------------------------------- Index Only Scan using test_table_pkey on public.test_table (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1) Output: id, context -> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1) Projections: id, context -> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1) Query Identifier: qymgw1m77maoe Planning Time: 11.415 ms Execution Time: 4.528 ms Statement DPU Estimate: Compute: 0.01607 DPU Read: 0.04312 DPU Write: 0.00000 DPU Total: 0.05919 DPU ``` Neste exemplo, a instrução SELECT executa uma verificação somente de índice, então a maior parte do custo vem da DPU de leitura (0,04312), representando os dados recuperados do armazenamento e da DPU de computação (0,01607), o que reflete os recursos computacionais utilizados para processar e exibir os resultados. Não há DPU de gravação, pois a consulta não modifica dados. A DPU total (0,05919) é a soma de computação \+ leitura \+ gravação. ### Exemplo 2: consulta INSERT ``` EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3'); ``` ``` QUERY PLAN ---------------------------------------------------- Insert on public.test_table (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1) -> Values Scan on "*VALUES*" (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1) Output: "*VALUES*".column1, "*VALUES*".column2 Query Identifier: jtkjkexhjotbo Planning Time: 0.068 ms Execution Time: 0.543 ms Statement DPU Estimate: Compute: 0.01550 DPU Read: 0.00307 DPU (Transaction minimum: 0.00375) Write: 0.01875 DPU (Transaction minimum: 0.05000) Total: 0.03732 DPU ``` Essa instrução executa principalmente gravações, portanto, a maior parte do custo está associada à DPU de gravação. A DPU de computação (0,01550) representa o trabalho realizado para processar e inserir os valores. A DPU de leitura (0,00307) reflete leituras secundárias do sistema (para pesquisas de catálogos ou verificações de índice). Observe os mínimos por transação exibidos entre parênteses ao lado das DPUs de leitura e gravação. Esses mínimos se aplicam no nível da transação, ou seja, o total de DPU de leitura ou de gravação de uma transação inteira nunca é inferior a esses valores. Se estiver usando `EXPLAIN ANALYZE VERBOSE` para prever custos e esta for a única instrução na transação, utilize os valores mínimos por transação em vez das estimativas brutas por instrução. Se a transação contiver várias instruções, os mínimos se aplicam ao total agregado de todas as instruções. Como `EXPLAIN ANALYZE VERBOSE` fornece estimativas no nível da instrução, enquanto o faturamento aplica mínimos no nível da transação, os valores podem não corresponder exatamente às métricas do CloudWatch ou aos dados de faturamento. ### Uso das informações de DPU para otimização As estimativas de DPU por instrução oferecem uma maneira poderosa de otimizar as consultas além do tempo de execução. Entre os casos de uso comuns estão: + **Conscientização sobre custos:** entenda o quanto uma consulta é cara em relação a outras. + **Otimização do esquema:** compare o impacto dos índices ou das alterações de esquema tanto no desempenho quanto na eficiência de recursos. + **Planejamento de orçamento:** estime o custo da workload com base no uso observado de DPU. + **Comparação de consultas:** avalie abordagens alternativas de consulta de acordo com base no consumo relativo de DPU. ### Interpretação das informações de DPU Lembre-se das seguintes práticas recomendadas ao usar dados de DPU de `EXPLAIN ANALYZE VERBOSE`: + **Use de forma direcionada:** trate a DPU relatada como uma forma de entender o custo *relativo* de uma consulta, em vez de uma correspondência exata com as métricas ou os dados de faturamento do CloudWatch. As diferenças são esperadas porque `EXPLAIN ANALYZE VERBOSE` indica o custo em nível de instrução, enquanto o CloudWatch agrega atividades em nível de transação. O CloudWatch também inclui operações em segundo plano (como ANALYZE assíncrono ou compactações) e sobrecarga de transação (`BEGIN`/`COMMIT`), que `EXPLAIN ANALYZE VERBOSE` exclui intencionalmente. + **Teste com dados representativos para provas de conceito:** ao executar uma prova de conceito para avaliar custos, garanta que as tabelas contenham volumes e distribuições de dados semelhantes à workload esperada em produção. As estimativas de DPU, sejam de `EXPLAIN ANALYZE VERBOSE` ou de métricas do CloudWatch, que se baseiam em tabelas vazias ou com poucos dados não refletem custos do mundo real. + A **variabilidade da DPU entre as execuções é normal** em sistemas distribuídos e não indica erros. Fatores como cache, mudanças no plano de execução, concorrência, operações em segundo plano como ANALYZE assíncrono ou alterações na distribuição de dados podem fazer com que a mesma consulta consuma recursos diferentes entre execuções. + **Agrupar operações pequenas:** se a workload emitir muitas instruções pequenas, considere agrupá-las em operações de gravação maiores dentro de uma única transação (as modificações não devem exceder 10 MB por transação, enquanto leituras são limitadas apenas pelo tempo limite de 5 minutos da transação). Isso dilui os mínimos por transação ao longo de mais trabalho e gera estimativas de custo mais significativas. + **Use para ajuste, não para cobrança:** os dados em `EXPLAIN ANALYZE VERBOSE`foram projetados para reconhecimento de custos, ajuste de consultas e otimização. Não é uma métrica de faturamento. Sempre confie nas métricas do CloudWatch ou nos relatórios de faturamento mensais para acessar dados confiáveis de custo e uso. ## Práticas recomendadas para estimativa de custos + **Monitore antes de otimizar:** use métricas do CloudWatch para entender o padrão atual de uso antes de tomar decisões de otimização. Para obter detalhes, consulte [Monitoramento do uso de DPU com o CloudWatch](#billing-cloudwatch-monitoring). + **Foque na eficiência da transação:** como os mínimos se aplicam no nível da transação, agrupe operações relacionadas para diluir as cobranças mínimas. + **Use EXPLAIN ANALYZE VERBOSE durante o desenvolvimento:** execute `EXPLAIN ANALYZE VERBOSE` em consultas críticas durante o desenvolvimento para entender as características de custo. Ao executar uma prova de conceito para avaliar custos, teste com tabelas que tenham volumes e distribuições de dados representativos. Estimativas baseadas em tabelas vazias ou com poucos dados não refletem os custos de produção. Para obter detalhes, consulte [Uso de EXPLAIN ANALYZE VERBOSE para conscientização sobre custos](#billing-explain-analyze). + **Configure alarmes no CloudWatch:** crie alarmes nas métricas de DPU para receber um aviso sobre picos inesperados de uso.