Sua tabela do Amazon DynamoDB pode armazenar milhões, bilhões, ou até trilhões de itens. Se você precisar realizar uma ação de atualização em massa (ou em lote) nos itens de uma tabela grande, é importante considerar o custo. Nesta postagem, eu mostro a você três técnicas para processamento de itens em massa de forma econômica com o DynamoDB.
Características do processamento em massa
Você pode ter várias razões para processar muitos itens de uma vez só, por exemplo:
- Excluir itens desatualizados por motivos de conformidade ou para reduzir os custos de armazenamento. A funcionalidade de Time to live (TTL), ou Tempo de Vida, do DynamoDB realiza a exclusão de itens de forma automática e sem custo, mas o atributo TTL deve existir em cada item a ser excluído. Talvez seus itens desatualizados tenham sido carregados sem um atributo TTL.
- Para preencher um valor apropriado de atributo TTL em itens mais recentes, para que eles sejam excluídos automaticamente de acordo com o cronograma adequado no futuro.
- Para preencher uma nova chave de partição ou chave de classificação de um índice secundário global (GSI) com um atributo completamente novo. Por exemplo, se a chave de classificação do GSI precisar ser uma combinação de estado e cidade (
<estado>#<cidade>), isso exigirá adicionar um novo atributo em cada item da tabela.
- Para aplicar quaisquer alterações em massa em que não seja necessário que o trabalho seja concluído imediatamente.
Uma característica comum do processamento em massa é que você não necessariamente precisa que seja feito imediatamente. Frequentemente, as solicitações em massa podem ser adiadas para o próximo segundo, a próxima hora, ou até mesmo o próximo dia. Isso permite designs inovadores para realizar o trabalho a um custo menor do que se tudo tivesse que ser executado imediatamente.
Neste post, vou assumir que você deseja realizar atualizações em massa sem interrupções, em uma tabela que também está recebendo tráfego orgânico (impulsionado pelo cliente). Também vou supor que você tenha uma tarefa de atualização em massa realmente grande, com bilhões de itens. Se a sua tarefa de atualização em massa for menor do que isso, o custo será tão baixo (independentemente de como você realizar o trabalho) que não exigirá abordagens mais cuidadosas como as descritas aqui.
Exemplo de custos em processamento de grande escala
Imagine que você tem uma tabela realmente grande: 500 bilhões de itens, cada um com 500 bytes de tamanho, totalizando uma tabela de aproximadamente 250TB. Esses dados se acumularam nos últimos 36 meses e agora você gostaria de remover todos os itens com um atributo de timestamp mais antigo que 13 meses. São 319 bilhões de itens que você precisa deletar. Imagine ainda que você gostaria de adicionar um atributo TTL aos outros 181 bilhões de itens, para que eles também sejam automaticamente deletados aos 13 meses de idade daqui para frente.
| Métrica |
Quantidade |
| Quantidade de itens |
500 bilhões |
| Tamanho do item |
500 bytes |
| Tamanho da tabela |
250 TB |
| Itens para deletar |
319 bilhões |
| Itens para atualizar |
181 bilhões |
Custo para modificar todos os itens usando o modo sob demanda
O custo de escrever (seja deletando ou atualizando) 500 bilhões de itens pequenos depende do modo da tabela. No modo sob demanda, será necessário exatamente 500 bilhões de unidades de requisições de escrita (WRUs). Não há vantagem com o modo sob demanda em controlar o momento das solicitações (exceto para distribuir o trabalho pela tabela e evitar partições superaquecidas). O cálculo desse custo para a região leste dos Estados Unidos (us-east-1) para uma tabela no modo sob demanda é o seguinte:
500 bilhões de WRUs ao preço de US$ 1,25 por milhão de operações = US$ 625.000
Também há custos de leitura a serem considerados. Uma operação de Scan pode extrair vários itens de uma vez. Usando leituras eventualmente consistentes, ele pode extrair dezesseis itens de 500 bytes por unidade de leitura consumida. Isso significa que a leitura de todos os 500 bilhões de itens exigirá cerca de 31,25 bilhões de unidades de solicitação de leitura (RRUs).
31,25 bilhões de RRUs ao preço de US$ 0,25 por milhão = US$ 7.810
Os custos de leitura são insignificantes em comparação com os custos das gravações, portanto, esta postagem se concentrará na otimização das gravações.
| Ação |
Quantidade necessária |
Custo por |
Custo Total |
500 bilhões de escrita
500 bytes item |
500 bilhões WRUs |
$1,25 a cada milhão |
$625.000,00 |
500 bilhões de leitura
500 Bytes item |
31,25 bilhões RRUs |
$0,25 a cada milhão |
$7.810,00 |
Isso equivale a cerca de 790.000 atualizações de itens para cada US$1 de custo. Como a carga de trabalho é previsível, podemos obter resultados muito melhores usando o modo provisionado.
Custo para modificar todos os itens usando o modo provisionado
No modo provisionado, o cálculo de preços é um pouco mais complicado. Isso ocorre porque as gravações em massa e as gravações orgânicas precisam coexistir de uma maneira que não exceda o limite de capacidade da tabela. É nessa relação de coexistência que encontraremos economias mais adiante neste post.
Nas tabelas provisionadas que lidam com o tráfego orgânico costumamos utilizar o Auto Scaling. O Auto Scaling ajusta a quantidade provisionada em resposta à quantidade consumida, visando manter a quantidade provisionada suficientemente acima da quantidade consumida para que picos temporários permaneçam dentro da quantidade provisionada.
As configurações de Auto Scaling incluem um valor mínimo (nunca dimensionar abaixo disso), um valor máximo (nunca dimensionar acima disso) e uma porcentagem de utilização alvo (a ideia é manter o consumo igual a este percentual da quantidade provisionada, com um valor padrão de 70%). A utilização alvo controla efetivamente quanto espaço é adicionado acima da quantidade consumida para determinar a quantidade provisionada. Números mais altos fornecem menos espaço adicional (aumentando o risco de throttling, ou estrangulamento).
Uma execução em massa constante que consome 1.000.000 WCUs (unidades de capacidade de gravação por segundo) será executada por 500.000 segundos (139 horas) para processar todos os 500 bilhões de itens. Durante esse tempo, a escalabilidade automática detectará o aumento do tráfego e provisionará um adicional de 1.428.500 WCUs (1.000.000 de WCUs divididos pelo objetivo de 70%) além do que for necessário para o tráfego orgânico.
Este é o cálculo de custo na região leste dos Estados Unidos (us-east-1) para uma tabela com capacidade no modo provisionado:
1.428.500 WCUs * 139 horas * US$ 0,00065 por WCU-hora = US$ 129.065
O custo relativamente menor da operação de Scan está incluído na tabela a seguir.
| Ação |
Quantidade consumida |
Quantidade provisionada |
Custo por |
Custo total |
500 bilhões de escrita
500 bytes item |
1.000.000 WRUs por 139 horas |
1.428.500 WCUs por 139 horas |
$0.00065 por WCU-hora |
$129.065,00 |
500 bilhões de leitura
500 bytes item |
62.500 RRUs por 139 horas |
89.285 RCUs por 139 horas |
$0.00013 por RCU-hora |
$1.614,00 |
Isso equivale a cerca de 3.826.000 atualizações de itens para cada $1 de custo, uma redução significativa nos custos em comparação com o modo sob demanda, como esperado para cargas de trabalho que não precisam da reatividade instantânea do modo sob demanda. O modo sob demanda pode, na verdade, ser mais econômico se o tráfego for irregular, mas o modo provisionado e seus preços fixos funcionam bem com cargas de trabalho mais ou menos constantes, como demonstrado.
Agora, vamos examinar três técnicas diferentes que usam o tempo para controlar quando e com que throughput o trabalho de gravação em massa é realizado para alcançar atualizações gratuitas ou ao menos com custo reduzido.
Usar capacidade reservada não utilizada
Se você comprou capacidade reservada, pode potencialmente usá-la para fornecer gravações em massa gratuitas, programando as gravações durante os períodos em que possui capacidade reservada não utilizada.
A capacidade reservada oferece um desconto em troca de um compromisso de um ou três anos para provisionar uma quantidade mínima de capacidade. Se você tem um tráfego diário que varia entre 300.000 WCUs e 700.000 WCUs, a quantidade ideal de capacidade reservada de um ano a ser adquirida estaria em torno de 500.000 WCUs. Comprar apenas no ponto mais baixo (300.000 WCUs) resultaria na perda de economias para toda a carga de trabalho acima da linha de referência, comprar no pico (700.000 WCUs) super dimensiona a capacidade durante a maior parte do dia, comprar em torno do ponto intermediário tende a ser o melhor.
Isso significa que sempre que o tráfego orgânico estiver entre 300.000 e 500.000 WCUs, uma operação de execução em massa cuidadosamente construída poderia preencher a lacuna e realizar a execução em massa sem custo adicional. Se você já se comprometeu com um mínimo de 500.000 WCUs, pode muito bem preencher o período de baixa utilização com execuções em massa.
O gráfico a seguir demonstra isso. A linha laranja irregular representa a capacidade consumida organicamente, flutuando ao longo do dia. A linha vermelha horizontal representa a quantidade de capacidade reservada adquirida. O espaço entre a linha horizontal e acima da linha de consumo irregular representa a oportunidade de gravações gratuitas.
Figura 1: Linha de gravações correspondente a capacidade reservada não utilizada
Imagine uma execução em lote parametrizada para consumir uma certa quantidade de capacidade auto limitada durante determinadas horas do dia, com base nas normas de consumo históricas. Por exemplo, se normalmente houver 200.000 WCUs reservadas, mas não utilizadas, durante o meio da noite, a execução em lote pode saber que deve consumir essas WCUs. Processando a uma taxa de 200.000 itens por segundo, todos os 500 bilhões de itens seriam processados em 694 horas. Supondo uma média de 30 horas por semana com esse nível de capacidade reservada não utilizada, levaria 13 semanas para processar o backlog.
Calcular as normas históricas é simples se você tiver apenas uma única tabela, mas requer trabalho adicional em uma organização maior. Isso ocorre porque a capacidade reservada não é atribuída a uma única tabela, mas é compartilhada entre todas as tabelas em uma determinada região em todas as contas conectadas à mesma conta pagadora. Não são apenas os períodos de baixa utilização em uma única tabela que importam, são os períodos de baixa utilização em todas as tabelas, e então é preciso calcular qual a quantidade de capacidade reservada não está sendo usado durante esses períodos. Essa é a taxa de execução a ser fornecida para execução em lote.
O Auto Scaling introduz complexidade neste design. Se você deixar o Auto Scaling no alvo padrão de 70%, você só poderá consumir efetivamente 140.000 WCUs, porque esse é o nível de gravação que resultará em todas as 200.000 WCUs sobressalentes sendo provisionadas para preencher a lacuna de utilização.
O que você pode fazer então é, durante as horas de execução em lote, ajustar as configurações do Auto Scaling para o valor mais agressivo possível de 90%. Isso reduz significativamente o preenchimento e permite que você consuma até 180.000 WCUs para atingir as 200.000 WCUs provisionadas.
Normalmente, se você definir uma meta de utilização agressiva, aumenta o risco de limitações durante picos de tráfego orgânico. Você pode mitigar isso fazendo com que a execução em lote se auto limite rapidamente e de forma rigorosa quando receber uma exceção do tipo ProvisionedThroughputExceededException, para que ele interrompa seu próprio consumo de taxa de transferência por um curto período de tempo para dar lugar ao tráfego orgânico. O preenchimento ainda está efetivamente lá, apenas sendo consumido de forma oportunista. Há menos necessidade de preenchimento com Auto Scaling conservador se o trabalho em lote puder eliminar seu consumo rapidamente. Certifique-se de ajustar as configurações de repetição do SDK para evitar repetições (automatic retries) automáticas ao implementar uma auto limitação rigorosa.
Essa abordagem, quando disponível, pode realizar todas as atualizações ao longo do tempo sem custos adicionais de serviço, mas requer um esforço de engenharia fixo no início.
Ajustar o Auto Scaling
Se você não tiver capacidade reservada não utilizada, mas estiver usando o modo provisionado com Auto Scaling, ajustar o Auto Scaling oferece outra maneira de alcançar gravações em massa praticamente gratuitas.
Conforme discutido no final da seção anterior, o objetivo da utilização do Auto Scaling é manter a linha de capacidade provisionada suficientemente acima da linha de capacidade consumida para que curtos picos de consumo não excedam a quantidade provisionada. Um alvo mais alto deixa menos espaço de preenchimento, enquanto um alvo mais baixo deixa mais espaço de preenchimento. A figura a seguir mostra como o Auto Scaling funciona. A linha laranja. irregular. representa o consumo da capacidade de escrita (WCUs) da tabela e as linhas azuis planas representam as capacidades de escritas (WCUs) provisionadas.
Figura 2: WCU consumido e provisionado com Auto Scaling
A técnica consiste então em aumentar a meta (o que diminui as linhas planas provisionadas), configurar a atualização em massa como uma porcentagem constante proporcional na sobre o tráfego orgânico (elevando um pouco a linha irregular e colocando a linha provisionada de volta onde estava originalmente), e fazer com que a execução em massa se auto limite ao receber exceções de throttling da tabela (o que torna aceitável ter a meta mais agressiva). Nesse caso, o processamento em massa é realizado a uma taxa proporcional a porcentagem do tráfego orgânico, sem custo adicional.
O gráfico a seguir demonstra esse cenário. A linha laranja inferior e irregular é o mesmo tráfego orgânico, as linhas azuis retas são a mesma quantidade provisionada, e a linha laranja superior e irregular é a capacidade consumida com um pouco de execução em massa adicionado. Aumentar a utilização da meta mantém as linhas retas no lugar, mesmo com a linha irregular mais alta.
Figura 3: Ajustar a utilização alvo e adicionar execução em massa sensível à limitação.
Ter um valor de utilização alvo mais alto permite menos margem para picos no tráfego. É por isso que você não teria naturalmente a meta mais alta do que é seguro. O valor excessivamente alto é aceitável aqui porque a execução em massa pode se auto limitar severamente (como já mencionado) sempre que recebe uma exceção de throttling, liberando imediatamente o throughput da tabela para o tráfego orgânico e tornando a distância completa entre as linhas laranja e azul disponível para picos orgânicos.
A execução em massa opera a uma porcentagem fixa do tráfego orgânico observado para preencher a lacuna aberta pela maior utilização alvo. Ao alterar a meta de 70%para 80%, abre-se a execução em massa para consumir aproximadamente 15% do tráfego orgânico à medida que sobe e desce, o que matematicamente mantém a linha provisionada em níveis aproximadamente iguais aos que seriam consumidos originalmente.
Aqui está a matemática confirmando que a mudança de 70% para 80% cento permite um aumento de 15%:=
- Suponha 500.000 WCUs de tráfego orgânico oscilante.
- Uma meta de 70% resulta em 500.000/0,7 = 714.285 WCUs provisionadas pelo Auto Scaling.
- Mude para uma meta de 80% e são 500.000/0,8 = 625.000 WCUs.
- Adicione 15% de execução em massa, alterando de 500.000 WCUs para 575.000 WCUs e agora são 575.000/0,8 = 718.750 WCUs provisionadas. Isso está bem próximo de onde começamos.
- A matemática exata é (80/70) – 1 = 14,3%. Se você mover uma meta de 50% para 70%, pode adicionar (70/50) – 1 = 40% de execução em massa.
Adicionar uma taxa média, mas variável, de 75.000 WCUs ao tráfego orgânico concluirá o backlog de 500 bilhões de itens em 11 semanas.
O desafio deste projeto está em manter a execução em massa em execução a uma porcentagem constante do tráfego orgânico, que pode variar. A execução em massa deve observar as métricas do Amazon CloudWatch para detectar a capacidade consumida geral (com alguns minutos de atraso), subtrair sua própria métrica história recente, determinar matematicamente o nível de uso orgânico e ajustar sua auto limitação para rodar como uma porcentagem fixa desse tráfego orgânico. É difícil ser preciso, por isso é melhor não ser muito agressivo na nova meta de utilização. Prefira 80% em vez de 90%, por exemplo.
Um desafio adicional: não é possível diferenciar entre uma exceção de throttling no nível da tabela e uma única partição quente causando uma exceção throttling. A execução em massa deve tender a se auto limitar severamente para evitar limitar o tráfego orgânico em ambos os casos. É importante que a execução em massa distribua uniformemente suas gravações entre as partições, como discutiremos mais adiante, para minimizar a frequência com que a execução em massa precisa pausar devido a uma partição quente.
Este enfoque, como o anterior, pode realizar todas as atualizações ao longo do tempo sem custos adicionais de serviço, mas requer uma quantidade fixa de esforço de engenharia no início.
Remover o Auto Scaling
Se você estiver usando capacidade provisionada e desejar controlar quanto tempo a execução em massa deve levar, ou se preferir um design com menos componentes móveis, remover o Auto Scaling oferece uma alternativa de processamento em massa econômica, embora não totalmente gratuita.
O que você faz é desativar o Auto Scaling, definir sua tabela com uma quantidade fixa de capacidade de gravação provisionada (em algum lugar acima do pico do tráfego orgânico) e permitir que a execução em massa preencha a lacuna entre o tráfego orgânico e o nível provisionado, certificando-se de definir a execução em massa para se auto limitar para garantir que o tráfego orgânico não seja limitado.
A economia de custos vem do fato de que, durante tempo de processamento em massa, o preenchimento normal necessário do Auto Scaling não é necessário. Se o processamento em massa durar 10 semanas, qualquer preenchimento que teria sido necessário durante essas semanas pode ser subtraído do custo do processamento em massa. O preenchimento não utilizado se torna tempo útil de processamento em massa.
A execução em massa precisa rastrear seu próprio consumo, observar no CloudWatch o consumo geral e se auto limitar para manter o consumo geral próximo ao nível provisionado. O processo também precisa se auto limitar severamente caso encontre uma exceção de throttling.
A meta de consumo deve ser um pouco abaixo de 100% para manter os benefícios da capacidade de burst para lidar com picos inesperados de gravação orgânica. A capacidade de burst permite que uma tabela funcione acima de sua capacidade provisionada por curtos períodos. A capacidade de burst é fornecida com base no melhor esforço, mas, quando disponível, ajuda sua tabela a evitar throttling se houver um pico orgânico, em vez disso, você verá limitações apenas após o término da capacidade de burst.
A quantidade disponível para burst é 300 vezes a capacidade provisionada por segundo. Por exemplo, uma tabela provisionada com 200.000 WCUs pode potencialmente oferecer 300.000 WCUs por 10 minutos ou 250.000 WCUs por 20 minutos antes de receber exceções de throttling (partições individuais não têm capacidade de burst). A capacidade de burst é reabastecida à medida que seu tráfego passa tempo abaixo da capacidade provisionada.
Manter uma folga de 5% abaixo do consumo total significa que após 100 minutos nesse nível, a concessão de capacidade de burst estaria totalmente restaurada após qualquer esgotamento total, portanto, visar 95% de consumo é um bom compromisso entre velocidade, eficiência de custos, e manutenção da disponibilidade de capacidade de burst. Se você antecipar mais picos na carga de trabalho orgânica, pode deixar uma porcentagem maior de folga.
O gráfico a seguir demonstra isso. A linha laranja, com picos, é o consumo orgânico, a linha azul plana é o valor provisionado típico e a linha vermelha pontilhada é a nova capacidade provisionada fixa. A execução em massa deve ser executada de forma a manter o consumo de capacidade um pouco abaixo da linha vermelha.
Figura 4: Desativar o Auto Scaling e usar execuções em lote para alcançar um consumo estável
Esta abordagem subtrai o custo inerente ao overhead do Auto Scaling (por exemplo, com uma utilização alvo de 70%, 30% do custo é dedicado apenas ao preenchimento) e alcança cerca de 95% de utilização para escritas orgânicas e também para escritas em lote.
Para a tabela de 500 bilhões de itens, vamos supor que você queira provisionar a uma taxa fixa de 800.000 WCUs porque isso está acima de qualquer pico esperado no tráfego orgânico usual que flutua entre 300.000 e 700.000 WCUs. O tráfego em lote preencherá a lacuna entre o tráfego orgânico e o alvo de 760.000 WCUs (respeitando essa margem de 5%). A taxa de tráfego em lote variará, mas como o tráfego orgânico tem média de 500.000 WCUs, a execução em lote terá uma média de 260.000 WCUs. Nessa taxa de escrita, processará todos os 500 bilhões de itens em três semanas.
Vamos considerar os custos. Durante essas três semanas, se não houvesse atividade em lote, esperaríamos uma média de 500.000 WCUs de tráfego orgânico e, com uma utilização alvo de 70%, isso resultaria em uma média de 714.285 WCUs provisionados. Em vez disso, optamos por provisionar um fixo de 800.000 WCUs. Por três semanas, executamos o processo em lote a uma taxa média de 260.000 WCUs, adicionando apenas um custo incremental de cerca de 85.000 WCUs. Isso significa que a execução em lote foi feita com uma redução de 67% do custo em comparação com escritas provisionadas totalmente utilizadas e uma redução de custo ainda maior em comparação com uma tabela com Auto Scaling.
No início deste post, calculamos que uma execução em lote contra uma tabela provisionada custaria $129.065. Esta abordagem consome uma média de 85.000 WCUs ao longo de três semanas, resultando em um custo total de:
85.000 WCUs * 21 dias * 24 horas * $0,00065 por hora-WCU = $27.846
Isso é cerca de 18.000.000 atualizações de itens por $1 de custo.
Comparando abordagens
O primeiro método – usar a capacidade reservada não utilizada – é direto e oferece, potencialmente, gravações em massa gratuitas, mas só funciona até o ponto em que se tem períodos repetidos e previsíveis de capacidade reservada subutilizada. Quanto mais longos e consistentes forem os períodos, mais rápido a execução em massa pode ser concluída.
O segundo método – apertar o Auto Scaling – é mais complexo. Ele alcança, potencialmente, gravações em massa gratuitas, com algum risco de aumento do throttling ou de o processamento em massa interferir no Auto Scaling baseado no tráfego orgânico de gravação. O risco pode ser controlado parametrizando a porcentagem da execução em massa adicionada ao tráfego orgânico.
O terceiro método – remover o Auto Scaling – é direto, deve executar o trabalho em massa mais rápido que a segunda opção, mas geralmente incorrerá em algum custo para o trabalho em massa, já que a linha de capacidade provisionada única provavelmente estará acima da média da linha de Auto Scaling. No entanto, o custo está sob seu controle, pois você escolhe o montante provisionado fixo e pode economizar o custo da capacidade excedente durante o tempo do trabalho em massa.
| Utilizar Capacidade Reservada não utilizada |
Apertar o Auto Scaling |
Remover o Auto Scaling |
| Resumo |
Converter capacidade reservada não utilizada em execução em massa durante períodos naturais de baixa utilização da capacidade reservada |
Elevar a meta do Auto Scaling e adicionar execução em massa (que se interrompe temporariamente para dar espaço a picos de trafego orgânico) para tornar a alta meta aceitável |
Provisionar um alto valor fixo e adicionar execução em massa (que se interrompe temporariamente para dar espaço a picos de trafego orgânico) para alcançar quase total utilização |
| Custo |
Gratuito |
Gratuito |
Baixo |
| Vantagens |
Design mais simples |
Funciona mesmo sem capacidade reservada |
Você controla a velocidade de execução, design direto |
| Desvantagens |
Deve estar utilizando capacidade reservada e ter períodos de baixa utilização previsíveis |
Design mais complexo |
Incorre em custo |
Distribuir a carga de gravação usando um Scan aleatório
Qualquer que seja a abordagem que você escolher, você vai querer distribuir a carga de escrita entre as partições da tabela, o que requer um cuidado extra se você estiver direcionando as escritas a partir de um Scan da tabela.
Ao fazer chamadas repetidas de Scan, você puxa uma página de cada vez. Cada chamada retorna o número de itens que você especificar como limite, até um máximo de 1 MB. Se a sua chamada ainda não chegou ao fim, sua resposta inclui o atributo LastEvaluatedKey, que você passa para a próxima chamada de Scan para puxar a próxima página. Internamente, a chamada Scan puxa itens de uma partição, e depois a seguinte.
Se você fizer o que parece natural e direcionar suas escritas diretamente dos itens retornados pelo Scan, você estará enviando suas escritas para a partição que o Scan estiver acessando naquele momento, criando o que chamamos de partição quente rotativa e limitando sua taxa de escrita para cerca de 1.000 WCUs por segundo (o limite fixo de escrita de uma partição).
Para evitar isso, você vai querer fazer um Scan embaralhado:
- Inicie um Scan paralelo.
- Especifique que você quer que o Scan use, por exemplo, 10.000 segmentos.
- Puxe 100 itens de um segmento (usando limite), depois puxe 100 de outro segmento escolhido aleatoriamente.
- Mantenha o controle da LastEvaluatedKey para cada número de segmento para que você possa reutilizá-la quando voltar a esse segmento novamente para ler o próximo bloco.
- Quando um segmento não retornar mais uma LastEvaluatedKey, você saberá que esse segmento foi totalmente lido e você não o lerá novamente.
- Quando todos os segmentos estiverem concluídos, a tabela inteira terá sido varrida em ordem embaralhada.
Isso puxa 100 itens de cada vez de 10.000 segmentos diferentes da tabela, efetivamente pulando de um lugar para outro para criar uma lista de trabalho bem distribuída pela tabela.
Se você criar execuções paralelas, pode dar a cada execução um conjunto aleatório de segmentos para que ele embaralhe. Isso permite que cada execução espalhe sua atividade pela tabela.
Conclusão
Escritas em massa, sejam elas exclusões, inserções ou atualizações, têm a característica única de que podem ser realizadas em um momento e a uma taxa escolhida para eficiência de custo.
Se você tem capacidade reservada, é possível obter escritas sem custo adicional, fazendo essas escritas quando os níveis de tráfego orgânico estão abaixo da reserva de capacidade mínima.
Se você estiver usando Auto Scaling, é possível obter escritas gratuitas ou quase gratuitas aumentando a porcentagem de utilização alvo e preenchendo a lacuna com escritas em massa, evitando problemas de throttling, fazendo com que a execução em massa se auto limite rigorosamente sempre que receber throttling.
Se você deseja um design simples ou um processamento mais rápido, pode obter escritas de baixo custo definindo uma quantidade fixa provisionada de WCU (sem Auto Scaling) e fazer o trabalho em massa consumir capacidade quase até esse valor fixo. A economia vem da remoção do custo usual do overhead de Auto Scaling durante o tempo de execução em massa.
Lembre-se de que, ao conduzir quaisquer escritas em massa a partir de um Scan na tabela, é importante espalhar as chamadas de Scan pela tabela, de modo a espalhar também as chamadas de escrita, evitando assim partições quentes. Você pode fazer isso usando um Scan embaralhado (construído com um Scan paralelo) que puxa um pequeno número de itens repetidamente de segmentos aleatórios.