Práticas recomendadas para consulta e verificação de dados - Amazon DynamoDB

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Práticas recomendadas para consulta e verificação de dados

Esta seção aborda algumas práticas recomendadas para o uso de operações Query e Scan no Amazon DynamoDB.

Considerações sobre desempenho para verificações

Em geral, as operações Scan são menos eficientes do que outras operações no DynamoDB. A operação Scan sempre verifica toda a tabela ou o índice secundário. Em seguida, ela filtra valores para fornecer o resultado desejado, adicionando, essencialmente, a etapa extra de remover os dados do conjunto de resultados.

Se possível, evite usar uma operação Scan em uma tabela ou índice grande com um filtro que remove muitos resultados. Além disso, conforme uma tabela ou índice cresce, a operação Scan torna-se mais lenta. A operação Scan examina todos os itens com os valores solicitados e pode usar o throughput provisionado para uma tabela ou índice grande em uma única operação. Para tempos de resposta mais rápidos, crie suas tabelas e índices de forma que suas aplicações possam usar Query, em vez de Scan. (Para tabelas, você também pode considerar usar GetItem e as APIs BatchGetItem.)

Como alternativa, é possível criar sua aplicação para usar operações Scan de uma forma que minimize o impacto na taxa de solicitações. Isso pode incluir modelagem quando for mais eficiente usar um índice secundário global em vez de uma operação Scan. Há mais informações sobre esse processo no vídeo a seguir.

Evitar picos súbitos na atividade de leitura

Ao criar uma tabela, você define seus requisitos de unidade de capacidade de leitura e gravação. Para leituras, as unidades de capacidade são expressas como o número de solicitações de leitura de dados de 4 KB fortemente consistentes por segundo. Para leituras finais consistentes, uma unidade de capacidade de leitura é duas solicitações de leitura de 4 KB por segundo. Uma operação Scan realiza leituras finais consistentes por padrão, e pode retornar até 1 MB (uma página) de dados. Portanto, uma única solicitação Scan pode consumir (tamanho de página de 1 MB/tamanho de item de 4KB)/2 (leituras finais consistentes) = 128 operações de leitura. Se você solicitasse leituras altamente consistentes em vez disso, a operação Scan consumiria duas vezes mais throughput provisionado (256 operações de leitura).

Isso representa um pico súbito no uso em comparação com a capacidade de leitura configurada para a tabela. Esse uso de unidades de capacidade por uma verificação impede que outras solicitações potencialmente mais importante para a mesma tabela use as unidades de capacidade disponíveis. Como resultado, você provavelmente receberá uma exceção ProvisionedThroughputExceeded para essas solicitações.

O problema não é apenas o aumento repentino nas unidades de capacidade usadas pelo Scan. A verificação provavelmente consumirá todas as suas unidades de capacidade da mesma partição, pois a verificação solicita itens de leitura que estão próximos uns dos outros na partição. Isso significa que a solicitação está alcançando a mesma partição, fazendo com que todas as suas unidades de capacidade sejam consumidas, e controlando a utilização de outras solicitações para essa partição. Se a solicitação para leitura de dados estiver dividida entre várias partições, a operação não limitará uma partição específica.

O diagrama a seguir ilustra o impacto de um pico súbito no uso de unidades de capacidade pelas operações Query e Scan, e seu impacto nas outras solicitações para a mesma tabela.


        Quatro cenários diferentes mostrando intervalos de throughput provisionado, solicitações e resultados bons e ruins em uma tabela.

Como ilustrado aqui, o pico de uso pode afetar o throughput provisionado da tabela de várias maneiras:

  1. Bom: distribuição uniforme de solicitações e tamanho

  2. Não tão bom: pedidos frequentes em rajadas

  3. Ruim: algumas solicitações grandes aleatórias

  4. Ruim: operações de verificação grandes

Em vez de usar uma operação Scan grande, você pode usar as técnicas a seguir para minimizar o impacto de uma verificação no throughput provisionado de uma tabela.

  • Reduzir o tamanho da página

    Como uma operação Scan lê uma página inteira (por padrão, 1 MB), você pode reduzir o impacto da operação Scan configurando um tamanho de página menor. A operação Scan fornece um parâmetro Limit que você pode usar para definir o tamanho da página para sua solicitação. Cada solicitação Query ou Scan com um tamanho de página menor usa menos operações de leitura e cria uma "pausa" entre cada solicitação. Por exemplo, suponha que cada item tem 4 KB e você definiu o tamanho da página para 40 itens. Uma solicitação Query consumiria apenas 20 operações de leitura final consistente ou 40 operações de leitura fortemente consistente. Um número maior de operações Query ou Scan menores permitiria que suas outras solicitações críticas tivessem êxito sem controle de utilização.

  • Operações de verificação isoladas

    O DynamoDB foi projetado para facilitar a escalabilidade. Como resultado, uma aplicação pode criar tabelas para fins distintos e, possivelmente, duplicar conteúdo em várias tabelas. Você deseja executar verificações em uma tabela que não está recebendo tráfego "essencial à missão". Algumas aplicações lidam com essa carga roteando tráfego entre duas tabelas por hora – uma para tráfego crítico e outra para fins de registro. Outras aplicações podem fazer isso, executando todas as gravações em duas tabelas: uma tabela de "missão crítica" e uma tabela de "sombra".

Você deve configurar sua aplicação para tentar novamente qualquer solicitação que receba um código de resposta que indica que você excedeu o throughput provisionado. Ou, aumente o throughput provisionado para sua tabela usando a operação UpdateTable. Se houver picos temporárias em sua workload que fazem com que o throughput exceda, ocasionalmente, o nível provisionado, tente novamente a solicitação com recuo exponencial. Para obter mais informações sobre a implementação de recuo exponencial, consulte Repetições de erro e recuo exponencial.

Aproveitar as verificações paralelas

Muitas aplicações podem se beneficiar do uso de operações Scan paralelas, em vez de verificações sequenciais. Por exemplo, uma aplicação que processa uma tabela de dados históricos grande pode executar uma verificação paralela muito mais rapidamente do que uma verificação sequencial. Vários threads de operadores em um processo de “varredura” em segundo plano poderiam verificar uma tabela com baixa prioridade sem afetar o tráfego de produção. Em cada um desses exemplos, uma operação Scan paralela é usada de forma a não enfraquecer outras aplicações de recursos de throughput provisionado.

Embora as verificações paralelas possam ser benéficas, elas podem representar uma demanda pesada sobre o throughput provisionado. Com uma verificação paralela, sua aplicação tem vários operadores que executam operações Scan simultâneas. Isso pode consumir rapidamente toda a capacidade de leitura provisionada da sua tabela. Nesse caso, outras aplicações que precisam acessar a tabela podem ter controle de utilização.

A verificação paralela pode ser a escolha certa se as seguintes condições forem cumpridas:

  • O tamanho da tabela é 20 GB ou maior.

  • O throughput de leitura provisionado da tabela não está sendo completamente utilizada.

  • Operações Scan sequenciais são muito lentas.

Escolhendo TotalSegments

A melhor configuração para TotalSegments depende de seus dados específicos, das configurações de throughput provisionado da tabela e de seus requisitos de performance. Você provavelmente precisará experimentar até obter os resultados desejados. Recomendamos começar com uma taxa simples, como um segmento por 2 GB de dados. Por exemplo, para uma tabela de 30 GB, você poderia definir TotalSegments até 15 (30 GB/2 GB). Sua aplicação poderia usar 15 operadores, com cada operador verificando um segmento diferente.

Você também pode escolher um valor para TotalSegments que seja baseado em recursos do cliente. Você pode definir TotalSegments como qualquer número de 1 a 1000000, e o DynamoDB permitirá que você execute uma verificação desse número de segmentos. Por exemplo, se o cliente limitar o número de threads que podem ser executados simultaneamente, você poderá aumentar TotalSegments gradualmente até obter a melhor performance de Scan com sua aplicação.

Você precisará monitorar suas verificações paralelas para otimizar a utilização de throughput provisionado e, ao mesmo tempo, garantir que suas outras aplicações não careçam de recursos. Aumente o valor de TotalSegments se você não consumir todo o throughput provisionado, mas ainda experimentar algum controle de utilização em suas solicitações de Scan. Reduza o valor de TotalSegments se as solicitações de Scan consomem mais throughput provisionado do que você deseja usar.