Gerenciar configurações em tabelas com capacidade provisionada do DynamoDB

Ao criar uma nova tabela provisionada no Amazon DynamoDB, especifique a capacidade de throughput provisionado. Essa é a quantidade de atividades de leitura e gravação que a tabela pode suportar. O DynamoDB usa essas informações para reservar recursos suficientes do sistema para atender aos seus requisitos de throughput.

nota

Você pode criar uma tabela de modo sob demanda em vez disso para que não precise gerenciar quaisquer configurações de capacidade para servidores, armazenamento ou throughput. O DynamoDB acomoda instantaneamente o crescimento e a redução das workloads para qualquer nível de tráfego previamente registrado. Se o nível de tráfego de uma workload atingir um novo pico, o DynamoDB fará adaptações rapidamente para acomodar a workload. Para ter mais informações, consulte Modo sob demanda.

Opcionalmente, você pode permitir que o Auto Scaling do DynamoDB gerencie a capacidade de throughput da tabela. No entanto, você ainda deve fornecer configurações iniciais para a capacidade de leitura e gravação ao criar a tabela. O Auto Scaling do DynamoDB usa essas configurações iniciais como um ponto de partida e, em seguida, as ajusta dinamicamente em resposta às exigências da sua aplicação. Para ter mais informações, consulte Gerenciar a capacidade de throughput automaticamente com o Auto Scaling do DynamoDB.

À medida que os dados do seu aplicativo e os requisitos de acesso mudam, talvez seja necessário ajustar as configurações de throughput da tabela. Se você estiver usando o Auto Scaling do DynamoDB as configurações de throughput serão automaticamente ajustadas em resposta às workloads reais. Também é possível usar a operação UpdateTable para ajustar manualmente a capacidade de throughput da tabela. Você pode optar por fazer isso se precisar fazer o carregamento em massa de dados de um armazenamento de dados existentes para sua nova tabela do DynamoDB. Você pode criar a tabela com uma configuração alta de throughput de gravação e, em seguida, reduzir essa configuração depois que o carregamento de dados em massa for concluído.

Você especifica os requisitos de throughput em termos de unidades de capacidade, a quantidade de dados que a sua aplicação precisa ler ou gravar por segundo. Você pode modificar essas configurações mais tarde, se necessário, ou permitir que o Auto Scaling do DynamoDB os modifique automaticamente.

Unidades de capacidade de leitura

Uma unidade de capacidade de leitura representa uma leitura altamente consistente por segundo ou duas leituras finais consistentes por segundo, para um item de até 4 KB de tamanho.

nota

Para saber mais sobre os modelos de consistência de leitura do DynamoDB, consulte Consistência de leituras.

Por exemplo, suponha que você crie uma tabela com 10 unidades de capacidade de leitura provisionadas. Isso permite que você execute 10 leituras altamente consistentes por segundo, ou 20 leituras finais consistentes por segundo para itens de até 4 KB.

Ler um item maior que 4 KB consome mais unidades de capacidade de leitura. Por exemplo, uma leitura altamente consistente de um item que tem 8 KB (4 KB × 2) consome 2 unidades de capacidade de leitura. Uma leitura final consistente nesse mesmo item consome apenas uma unidade de capacidade de leitura.

Os tamanhos de item para leituras são arredondados para o próximo múltiplo de 4 KB. Por exemplo, ler um item com 3.500 bytes consome a mesmo throughput que a leitura de um item de 4 KB.

Consumo de unidades de capacidade para leituras

A tabela a seguir descreve como as operações de leitura do DynamoDB consomem unidades de capacidade de leitura:

• GetItem: lê um único item de uma tabela. Para determinar o número de unidades de capacidade que o GetItem consumirá, arredonde o tamanho do item até o próximo limite de 4 KB. Se você especificou uma leitura altamente consistente, este é o número de unidades de capacidade necessárias. Para uma leitura final consistente (o padrão), divida esse número por dois.

  Por exemplo, se você ler um item que tem 3,5 KB, o DynamoDB arredondará o tamanho do item para 4 KB. Se você ler um item de 10 KB, o DynamoDB arredondará o tamanho do item para 12 KB.

• BatchGetItem: lê até 100 itens de uma ou mais tabelas. O DynamoDB processa cada item no lote como uma solicitação GetItem individual. Assim, o DynamoDB primeiro arredonda o tamanho de cada item para o próximo limite de 4 KB e, em seguida, calcula o tamanho total. O resultado não é necessariamente o mesmo que o tamanho total de todos os itens. Por exemplo, se BatchGetItem ler um item de 1,5 KB e outro de 6,5 KB, o DynamoDB calculará o tamanho como 12 KB (4 KB + 8 KB), e não 8 KB (1,5 KB + 6,5 KB).

• Query: lê vários itens que têm o mesmo valor de chave de partição. Todos os itens retornados são tratados como uma única operação de leitura, onde o DynamoDB calcula o tamanho total de todos os itens e arredonda para o próximo limite de 4 KB. Por exemplo, suponha que a consulta retorne 10 itens cujo tamanho combinado é 40,8 KB. O DynamoDB arredonda o tamanho do item da operação para 44 KB. Se uma consulta retornar 1.500 itens de 64 bytes cada, o tamanho cumulativo será 96 KB.

• Scan: lê todos os itens em uma tabela. O DynamoDB considera o tamanho dos dados avaliados, não o tamanho dos dados retornados pelo escaneamento.

Se você realizar uma operação de leitura em um item que não existe, o DynamoDB ainda consumirá o throughput de leitura provisionado: uma solicitação de leitura altamente consistente consome uma unidade de capacidade, enquanto uma solicitação de leitura final consistente consome 0,5 de uma unidade de capacidade.

Para qualquer operação que retorna itens, você pode solicitar um subconjunto de atributos a serem recuperados. No entanto, isso não tem nenhum impacto sobre os cálculos de tamanho dos itens. Além disso, Query e Scan podem retornar as contagens de itens, em vez de valores de atributo. A obtenção da contagem de itens usa a mesma quantidade de unidades de capacidade de leitura e está sujeita aos mesmos cálculos de tamanho de item. Isso ocorre porque o DynamoDB precisa ler cada item para aumentar a contagem.

Operações de leitura e consistência de leitura

Os cálculos anteriores presumem solicitações de leitura altamente consistentes. Para uma solicitação de leitura final consistente, a operação consome apenas metade das unidades de capacidade. Para uma leitura final consistente, se o tamanho total do item for 80 KB, a operação consumirá apenas 10 unidades de capacidade.

Unidades de capacidade de gravação

Uma unidade de capacidade de gravação representa uma gravação por segundo para um item de até 1 KB de tamanho.

Por exemplo, suponha que você crie uma tabela com 10 unidades de capacidade de gravação. Isso permite que você execute 10 gravações por segundo para itens de até 1 KB de tamanho por segundo.

Os tamanhos de item para gravações são arredondados até o próximo múltiplo de 1 KB. Por exemplo, gravar um item de 500 bytes consome a mesmo throughput que gravar um item de 1 KB.

Consumo de unidade de capacidade para gravações

A tabela a seguir descreve como as operações de gravação do DynamoDB consomem unidades de capacidade de gravação:

• PutItem: grava um único item em uma tabela. Se um item com a mesma chave primária existe na tabela, a operação substitui o item. Para calcular o consumo de throughput provisionado, o tamanho do item que importa é o maior dos dois.

• UpdateItem: modifica um único item na tabela. O DynamoDB considera o tamanho do item como ele aparece antes e depois da atualização. O throughput provisionado consumido reflete o maior desses tamanhos de item. Mesmo se você atualizar apenas um subconjunto dos atributos do item, UpdateItem ainda consumirá a quantidade total do throughput provisionado (o maior dos tamanhos de item de “antes” e “depois”).

• DeleteItem: remove um único item de uma tabela. O consumo de throughput provisionado é baseado no tamanho do item excluído.

• BatchWriteItem: grava até 25 itens em uma ou mais tabelas. O DynamoDB processa cada item no lote como uma solicitação PutItem ou DeleteItem individual (atualizações não são compatíveis). Então, o DynamoDB primeiro arredonda o tamanho de cada item para o próximo limite de 1 KB e, em seguida, calcula o tamanho total. O resultado não é necessariamente o mesmo que o tamanho total de todos os itens. Por exemplo, se BatchWriteItem gravar um item de 500 bytes e um item de 3,5 KB, o DynamoDB calculará o tamanho como 5 KB (1 KB + 4 KB), e não como 4 KB (500 bytes + 3,5 KB).

Para operações PutItem, UpdateItem e DeleteItem, o DynamoDB arredonda o tamanho do item até o próximo 1 KB. Por exemplo, se você inserir ou excluir um item de 1,6 KB, o DynamoDB arredondará o tamanho do item até 2 KB.

PutItem, UpdateItem e DeleteItem permitem gravações condicionais, onde você especifica uma expressão que deve ser verdadeira para a operação ter êxito. Se a expressão for falsa, o DynamoDB ainda consumirá unidades de capacidade de gravação da tabela. A quantidade consumida dependerá do tamanho do item (seja um item existente na tabela ou um item que você está tentando criar ou atualizar). Por exemplo, se um item existente tiver 300 kb e o item que você está tentando criar ou atualizar tiver 310 kb, as unidades de capacidade de gravação consumidas serão equivalentes ao item de 310 kb.

Controle de utilização de solicitações e capacidade de expansão

Se a sua aplicação executar leituras ou gravações a uma taxa mais alta do que a aceita pela sua tabela compatível, o DynamoDB começará a limitar essas solicitações. Quando o DynamoDB limita uma leitura ou gravação, ele retorna uma ProvisionedThroughputExceededException para o chamador. Em seguida, a aplicação pode executar a ação apropriada, como esperar por um curto intervalo antes de repetir a solicitação.

nota

Recomendamos que você use os AWS SDKs para desenvolvimento de software. Os AWS SDKs fornecem suporte integrado à repetição de solicitações com limitação; você não precisa escrever essa lógica. Para ter mais informações, consulte Repetições de erro e recuo exponencial.

O console do DynamoDB exibe métricas da CloudWatch Amazon para suas tabelas, para que você possa monitorar solicitações limitadas de leitura e gravação. Se você encontrar um número excessivo de controle de utilização, considere aumentar suas configurações de throughput provisionado da tabela.

Em alguns casos, o DynamoDB usa a capacidade de expansão para acomodar leituras ou gravações em excesso das configurações de throughput da tabela. Com a capacidade de expansão, as solicitações de leitura ou gravação inesperadas podem ter êxito onde, de outra forma, seriam limitadas. Para ter mais informações, consulte Usar a capacidade de expansão eficientemente.

Controle de utilização de solicitações e capacidade adaptativa

O DynamoDB distribui automaticamente seus dados entre partições, que são armazenadas em vários servidores na AWS nuvem (para obter mais informações, consulte). Partições e distribuição de dados Não é sempre possível distribuir a atividade de leitura e gravação uniformemente o tempo todo. Quando o acesso aos dados é desequilibrado, uma partição “dinâmica” pode receber um volume mais alto de tráfego de leitura e gravação em comparação com outras partições. A capacidade adaptável funciona por meio do aumento automático da capacidade de throughput para as partições que recebem mais tráfego. Para ter mais informações, consulte Noções básicas da capacidade de expansão do DynamoDB.

Escolher as configurações iniciais de throughput

Cada aplicação tem diferentes requisitos para ler e gravar a partir de um banco de dados. Quando estiver determinando as configurações iniciais de throughput de uma tabela do DynamoDB, leve as seguintes entradas em consideração:

• Tamanhos de itens. Alguns itens são pequenos o suficiente para que possam ser lidos ou gravados usando uma única unidade de capacidade. Itens maiores exigem várias unidades de capacidade. Ao estimar os tamanhos dos itens que estarão em sua tabela, você pode especificar configurações precisas para seu throughput provisionado.

• Taxas de solicitações de leitura e de gravação esperadas. Além do tamanho do item, você deve estimar o número de leituras e gravações que você precisa executar por segundo.

• Leia os requisitos de consistência. As unidades de capacidade de leitura se baseiam em operações de leitura altamente consistentes, que consomem duas vezes mais recursos de banco de dados que as leituras finais consistentes. Você deve determinar se o seu aplicativo requer leituras altamente consistentes, ou se ele pode ignorar essa exigência e executar leituras finais consistentes em vez disso. (As operações de leitura no DynamoDB são finais consistentes, por padrão. Você poderá solicitar leituras altamente consistentes para essas operações, se necessário.)

Por exemplo, suponha que você queira ler 80 itens por segundo de uma tabela. Os itens têm 3 KB de tamanho e você deseja leituras altamente consistentes. Para esse cenário, cada leitura requer uma unidade de capacidade de leitura provisionada. Para determinar esse número, divida o tamanho do item da operação por 4 KB e, em seguida, arredonde o resultado até o número inteiro mais próximo, como neste exemplo:

• 3 KB / 4 KB = 0,75 ou 1 unidade de capacidade de leitura

Para esse cenário, você precisa definir o throughput de leitura provisionado da tabela como 80 unidades de capacidade de leitura:

• 1 unidade de capacidade de leitura por item × 80 leituras por segundo = 80 unidades de capacidade de leitura

Agora, vamos supor que você queira gravar 100 itens por segundo na tabela e que esses itens tenham 512 bytes. Para esse cenário, cada gravação requer uma unidade de capacidade de gravação provisionada. Para determinar esse número, divida o tamanho do item da operação por 1 KB e, em seguida, arredonde o resultado até o número inteiro mais próximo:

• 512 bytes / 1 KB = 0,5 ou 1

Para esse cenário, você gostaria de definir o throughput provisionado de gravação da tabela como 100 unidades de capacidade de gravação:

• 1 unidade de capacidade de gravação por item × 100 gravações por segundo = 100 unidades de capacidade de gravação

nota

Para obter recomendações sobre throughput provisionado e tópicos relacionados, consulte Práticas recomendadas para projetar e usar chaves de partição efetivamente.

Modificar as configurações de throughput

Se você tiver habilitado o Auto Scaling do DynamoDB para uma tabela, sua capacidade de throughput será ajustada dinamicamente em resposta ao uso real. Nenhuma intervenção manual é necessária.

Você pode modificar as configurações de taxa de transferência provisionada da tabela usando a operação AWS Management Console ou a. UpdateTable Para obter mais informações sobre aumentos e diminuições de throughput por dia, consulte Service quotas, conta e cotas de tabela no Amazon DynamoDB.

Solucionar problemas de controle de utilização

Para solucionar problemas que parecem estar relacionados ao controle de utilização, é importante confirmar se o controle de utilização vem do DynamoDB ou da aplicação.

Veja a seguir alguns cenários comuns e possíveis etapas para ajudar a resolvê-los.

A tabela do DynamoDB parece ter capacidade provisionada suficiente, mas as solicitações estão sendo controladas.

Isso pode ocorrer quando o throughput está abaixo da média por minuto mas excede a quantidade disponível por segundo. O DynamoDB reporta apenas métricas em nível de minuto CloudWatch para, que são então calculadas como a soma de um minuto e calculadas a média. Mas o próprio DynamoDB aplica limites de taxa por segundo. Portanto, se uma parte significativa desse throughput ocorrer em uma pequena parte desse minuto, como alguns segundos ou menos, as solicitações para o restante desse minuto poderão ser controladas. Por exemplo, se tivermos provisionado 60 WCU em uma tabela, ela poderá fazer 3.600 gravações em um minuto. Mas se todas as 3.600 solicitações de WCU forem atendidas no mesmo segundo, o restante desse minuto será controlado.

Uma forma de resolver esse cenário pode ser adicionar um pouco de instabilidade e recuo exponencial às chamadas de API. Para obter mais informações, consulte esta publicação sobre recuo e oscilação.

A escalabilidade automática está ativada, mas as tabelas ainda estão sendo controladas.

Isso pode ocorrer durante picos repentinos no tráfego. O escalonamento automático pode ser acionado quando dois pontos de dados violam o valor de utilização alvo configurado em um período de um minuto. Portanto, o escalonamento automático pode ocorrer porque a capacidade consumida está acima da meta de utilização por dois minutos consistentes. Mas se os picos tiverem mais de um minuto de diferença, o escalonamento automático pode não ser acionado. Da mesma forma, um evento de redução de escala verticalmente pode ser acionado quando quinze pontos de dados consecutivos estão abaixo da meta de utilização. Em ambos os casos, depois que o escalonamento automático é acionado, uma UpdateTablechamada é invocada. Em seguida, pode levar alguns minutos para atualizar a capacidade provisionada da tabela ou do índice. Durante esse período, todas as solicitações que excederem a capacidade provisionada anterior das tabelas serão limitadas.

Em resumo, a escalabilidade automática exige pontos de dados consecutivos em que o valor de utilização alvo está sendo violado para aumentar a escala de uma tabela do DynamoDB verticalmente. Por esse motivo, a escalabilidade automática não é recomendada como uma solução para lidar com workloads aumentadas. Consulte a Documentação sobre escalabilidade automática para obter mais informações.

As tabelas estão no modo de capacidade “Sob demanda”, mas ainda estão sendo controladas.

Para tabelas sob demanda, o DynamoDB aloca automaticamente mais capacidade à medida que o volume de tráfego aumenta. Desde que o acesso seja distribuído uniformemente entre as partições e a tabela não exceda o dobro do pico de tráfego anterior, a tabela geral não será controlada. No entanto, poderá ocorrer controle de utilização se o throughput exceder o dobro do pico anterior em trinta minutos. Consulte o OnDemand escalonamento para obter mais informações.

Uma tecla de atalho pode estar causando problemas de controle de utilização.

No DynamoDB, uma chave de partição que não tem alta cardinalidade pode ocasionar muitas solicitações que visam apenas algumas partições. Se uma “partição quente” resultante ultrapassar os limites por partição de 3.000 RCU ou 1.000 WCU por segundo, isso pode ocasionar controle de utilização. A ferramenta de diagnóstico CloudWatch Contributor Insights pode ajudar a depurar isso, fornecendo gráficos CCI para os padrões de acesso aos itens de cada tabela. Você pode monitorar continuamente as chaves acessadas com maior frequência das tabelas do DynamoDB e outras tendências de tráfego. Para saber mais sobre o CloudWatch Contributor Insights, consulte CCI. Para obter informações específicas sobre como selecionar a tecla de atalho correta, consulte Choosing the right hot key (Selecionar a tecla de atalho correta).

Usando CloudWatch métricas para investigar a limitação

Veja algumas métricas do DynamoDB a serem monitoradas durante eventos de controle de utilização, para ajudar a localizar quais operações estão criando solicitações controladas e identificar problemas básicos.

1. ThrottledRequests

• Uma solicitação controlada pode conter vários eventos controlados, para que os eventos possam ser mais relevantes para serem examinados.

  Por exemplo, ao atualizar um item em uma tabela com GSIs, haverá vários eventos: uma gravação na tabela e uma gravação em cada índice. Mesmo que um ou mais desses eventos sejam limitados, haverá apenas um. ThrottledRequest

2. ReadThrottleEvents

• Observe as solicitações que excedem o RCU provisionado para uma tabela ou GSI.

3. WriteThrottleEvents

• Observe as solicitações que excedem o WCU provisionado para uma tabela ou GSI.

4. OnlineIndexConsumedWriteCapacity

• Preste atenção ao número de WCU consumido ao adicionar um novo GSI a uma tabela. Observe que ConsumedWriteCapacityUnits para um GSI não inclui o WCU consumido durante a criação do índice.

• Se você tiver configurado o WCU para um GSI muito baixo, a atividade de gravação de entrada durante a fase de alocação poderá ser controlada.

5. OnlineIndexThrottleEvents

• Revise o número de eventos de controle de utilização de gravação que ocorrem ao adicionar um novo GSI a uma tabela.

• Se você achar que o WCU está muito baixo e está sendo controlado, você pode atualizar o valor de WCU para um GSI mesmo durante a alocação.

6. Provisioned Read/Write

• Veja quantas unidades de capacidade de leitura ou gravação provisionadas foram consumidas durante o período especificado, para uma tabela ou um índice secundário global especificado.

• Observe que a dimensão TableName retorna ProvisionedReadCapacityUnits para a tabela somente por padrão. Para visualizar o número de unidades de capacidade de leitura ou gravação provisionadas para um índice secundário global, você deve especificar TableName e GlobalSecondaryIndexName.

7. Consumed Read/Write

• Veja quantas unidades de capacidade de leitura ou gravação foram consumidas durante o período especificado.

Para obter mais informações sobre métricas do CloudWatch DynamoDB, consulte Métricas e dimensões.