P: O que é o Amazon DynamoDB?

O Amazon DynamoDB é um serviço de banco de dados NoSQL de gestão completa que fornece um desempenho rápido e previsível com facilidade de escalabilidade. O Amazon DynamoDB permite aos clientes redirecionar as cargas administrativas de operação, assim como escalar bancos de dados distribuídos para a AWS. Dessa forma, os clientes ficam isentos de preocupações com provisionamento, instalação e configuração de hardware, replicação, patches de software ou escalabilidade de cluster.

P: O que o Amazon DynamoDB pode administrar em meu nome?

O Amazon DynamoDB elimina um dos maiores empecilhos da escalabilidade de bancos de dados, a gestão do software de banco de dados e o provisionamento de hardware necessário para executá-lo. Os clientes podem implantar um banco de dados não relacional em apenas alguns minutos. O DynamoDB faz o particionamento e o reparticionamento de seus dados e fornece capacidade de servidor adicional, à medida que sua tabela aumenta de tamanho, ou sua taxa de transferência provisionada é aumentada. Além disso, o Amazon DynamoDB replica simultaneamente os dados através de três recursos em uma região da AWS, proporcionado maior disponibilidade e durabilidade de dados.

P: O que significa consistência de leitura? Por que devo me preocupar?

O Amazon DynamoDB armazena três réplicas geograficamente distribuídas de cada tabela para permitir maior disponibilidade e durabilidade de dados. A consistência de leitura representa a forma e o momento em que a gravação bem-sucedida ou a atualização de uma gravação de item de dados é refletida em uma operação de leitura posterior desse mesmo item. O Amazon DynamoDB apresenta uma lógica que permite que você especifique as características de consistência desejadas para cada solicitação de leitura dentro de seu aplicativo.

P: O que é o modelo de consistência do Amazon DynamoDB?

Ao fazer a leitura de dados no Amazon DynamoDB, os usuários podem especificar se desejam que a leitura seja eventualmente consistente ou fortemente consistente:

Leituras eventualmente consistentes (Padrão) – a opção de consistência eventual maximiza sua taxa de transferência de leitura. Contudo, uma leitura eventualmente consistente pode não refletir os resultados de uma gravação concluída recentemente. A consistência em todas as cópias de dados normalmente é atingida em um segundo; após alguns instantes, a repetição de uma leitura deve retornar os dados atualizados.

Leituras fortemente consistentes – além da consistência eventual, o Amazon DynamoDB também proporciona a flexibilidade e o controle de solicitar uma leitura fortemente consistente se isso for exigido pelo aplicativo ou por um elemento do aplicativo. Uma leitura fortemente consistente retorna um resultado que reflete todas as gravações que receberam uma resposta bem-sucedida antes da leitura.

P: O DynamoDB suporta atualizações atômicas existentes?

O Amazon DynamoDB suporta atualizações atômicas rápidas. É possível aumentar ou diminuir um atributo numérico em uma fila usando uma chamada API única. Do mesmo modo, também é possível adicionar ou remover de um conjunto de sequências de caracteres automaticamente. Veja nossa documentação para saber mais sobre atualizações atômicas.

P: Por que o Amazon DynamoDB é estruturado com discos de estado sólido?

O Amazon DynamoDB é executado exclusivamente em discos de estado sólido (SSDs). Os SSDs ajudam a atingir objetivos em projetos de momentos de resposta previsível de baixa latência para armazenar e acessar dados em qualquer dimensão. O alto desempenho de E/S dos SSDs também nos permite atender a solicitações de grandes cargas de trabalho com boa relação custo-benefício e oferecer essa eficiência a preços acessíveis.

P: O custo para armazenamento no DynamoDB parece alto. É um serviço com boa relação custo-benefício para o meu caso de uso?

Assim como com qualquer produto, incentivamos os possíveis clientes do Amazon DynamoDB a considerar o custo total de uma solução, não apenas o valor de um preço específico. O custo total da prestação de serviços para cargas de trabalho de bancos de dados é uma função dos requisitos de tráfego de solicitações e da quantidade de dados armazenados. A maioria das cargas de trabalho de banco de dados é caracterizada por uma solicitação para E/S elevada (leituras/segundo e gravações/segundo altas) por GB armazenado. O Amazon DynamoDB é estruturado com discos de estado sólido, que aumentam os custos por GB armazenado, relativo a mídia rotativa, o que nos permite também oferecer preços muito acessíveis. Com base no que sabemos a respeito de cargas de trabalho de banco de dados típicas, acreditamos que o custo total para a utilização do serviço do DynamoDB baseado em SSD será usualmente mais baixo que o custo de utilização de um banco de dados típico relacional ou não relacional com base em uma mídia rotatória. Se você tiver um caso de uso que envolva o armazenamento de uma grande quantidade de dados raramente acessados, então o DynamoDB pode não ser adequado. Recomendamos que use o S3 para casos como esse.

Também é importante notar que o custo de armazenamento reflete o custo de armazenar várias cópias de cada item de dados por meio de vários recursos em uma região AWS.

P: O DynamoDB é só para aplicativos de alto nível?

Não. O DynamoDB oferece facilidade de escalabilidade para que você possa iniciar com demandas pequenas, aumentando e diminuindo a escala conforme a necessidade. Caso necessite de um desempenho rápido e previsível em qualquer escala, o DynamoDB pode ser a escolha certa para você.


P: Como começo a utilizar o Amazon DynamoDB?

Clique em "Cadastrar-se" para começar a usar o Amazon DynamoDB hoje. A partir daí, você pode começar a utilizar o Amazon DynamoDB usando tanto o AWS Management Console quanto APIs do Amazon DynamoDB. Caso você já seja usuário do AWS Management Console, é possível criar uma tabela com o Amazon DynamoDB e começar a explorar com apenas alguns cliques.

P: Que tipo de funcionalidade de consulta o DynamoDB suporta?

O Amazon DynamoDB suporta operações de valor-chave GET/PUT, usando uma chave primária definida pelo usuário. A chave primária é o único atributo solicitado para itens em uma tabela e identifica cada item especificamente. A chave primária é especificada quando você cria uma tabela. Além disso, o DynamoDB oferece uma funcionalidade flexível de consultas que permite a consulta sobre atributos que não são chaves primárias, usando índices secundários globais e índices secundários locais.

Uma chave primária pode tanto ser uma chave de hash de atributo único quanto uma chave de faixa de hash composta. Uma chave primária de hash de atributo único pode ser, por exemplo, "UserID". Isso permitiria a rápida leitura e gravação de dados para cada item associado a uma determinada ID do usuário.

Uma chave de faixa de hash composta é indexada como um elemento de chave de hash e um elemento de chave de faixa. Essa chave multipartes mantêm uma hierarquia entre o primeiro e o segundo valores de elemento. Por exemplo, uma chave de faixa de hash composta pode ser uma combinação de "UserID" (hash) e "carimbo de data/hora" (faixa). Mantendo a constante do elemento de chave hash, é possível pesquisar por meio do elemento de chave de faixa para recuperar itens. Isso permitiria o uso da API Query para, por exemplo, recuperar todos os itens para uma UserID específica em uma faixa de carimbo de data/hora.

Para obter mais informações sobre o índice secundário global e suas capacidades de pesquisa, veja a seção de índices secundários nas perguntas frequentes.

P: Como eu posso atualizar e consultar itens de dados com o Amazon DynamoDB?

Depois de criar uma tabela usando o AWS Management Console ou a API CreateTable, você poderá usar as APIs PutItem ou BatchWriteItem para inserir um item. Então é possível usar GetItem, BatchGetItem, ou, se chaves primárias compostas estiverem ativadas e em uso na tabela, usar a API Query para recuperar os itens que você adicionou à tabela.

P: O Amazon DynamoDB suporta operações condicionais?

Sim, é possível especificar uma condição a ser cumprida para que uma operação put, update ou delete em um item seja concluída. A condição pode ser definida em cada atributo usando operadores de comparação. Múltiplas condições também podem ser especificadas, conectadas pelos operadores “AND” ou “OR”. Quando o operador “AND” é usado, a operação de atualização é processada se todas as condições forem verdadeiras, e quando o operador “OR” é usado, se ao menos uma condição for verdadeira. As operações condicionais permitem aos usuários implementar sistemas de controle de simultaneidade otimista no DynamoDB. Para saber mais sobre operações condicionais, consulte a documentação.

P: O Amazon DynamoDB suporta operações de decremento ou de incremento?

Sim, o Amazon DynamoDB permite operações de decremento e incremento atômico em valores escalares.

P: Quando eu devo usar o Amazon DynamoDB em vez de um mecanismo de banco de dados relacional no Amazon RDS ou do Amazon EC2?

Os aplicativos baseados na web atuais geram e consomem quantidades massivas de dados. Por exemplo, um jogo on-line pode começar com apenas alguns milhares de usuários e uma carga de trabalho de banco de dados leve, consistindo em 10 gravações por segundo e 50 leituras por segundo. No entanto, se o jogo obtiver sucesso, é possível crescer rapidamente para um milhão de usuários e gerar dezenas (ou até centenas) de milhares de gravações e leituras por segundo. É possível também criar terabytes de dados por dia, ou ainda mais. Desenvolver seus aplicativos junto ao Amazon DynamoDB permite que você comece com uma demanda pequena e simplesmente aumente a capacidade de solicitações para uma tabela, à medida que suas solicitações aumentam, sem incorrer em tempo ocioso. Você paga tarifas com uma boa relação custo-benefício para a capacidade de solicitação provisionada, e deixa o Amazon DynamoDB fazer o trabalho desde o particionamento de dados e tráfego até os recursos de servidor suficientes para satisfazer as suas necessidades. O Amazon DynamoDB faz a gestão e a administração de banco de dados e você simplesmente armazena e requisita seus dados. Replicação e failovers automáticos fornecem tolerância de falha integrada, maior disponibilidade e durabilidade de dados. O Amazon DynamoDB lhe proporciona a tranquilidade de que seu banco de dados tem uma gestão completa e pode crescer com as solicitações de seu aplicativo.

Embora o Amazon DynamoDB solucione os principais problemas de escalabilidade, gestão, desempenho e confiabilidade de banco de dados, ele não possui todas as funcionalidades de um banco de dados relacional. Não suporta consultas relacionais complexas (p. ex., associações) ou transações complexas. Se sua carga de trabalho precisa dessa funcionalidade, ou se estiver procurando compatibilidade com um mecanismo relacional existente, você pode querer executar um mecanismo relacional no Amazon RDS ou Amazon EC2. Enquanto mecanismos de banco de dados relacionais fornecem funcionalidades e recursos robustos, escalar uma carga de trabalho além de uma instância de banco de dados relacional específica é altamente complexo e requer tempo e experiência significativos. Do mesmo modo, se você já sabe os requisitos de escalabilidade para seu novo aplicativo, não precisando de recursos relacionais, o Amazon DynamoDB pode ser a sua melhor escolha.

P: Como o Amazon DynamoDB se diferencia do Amazon SimpleDB?

Qual eu devo usar?Os dois serviços são bancos de dados não relacionais que eliminam a tarefa de administração de banco de dados. O Amazon DynamoDB se concentra no provisionamento de escalabilidade contínua e desempenho rápido e previsível. É executado em discos de estado sólido (SSDs) para momentos de respostas de baixa latência, sem limites da capacidade de requisição ou do tamanho de armazenamento para uma tabela específica. É por isso que o Amazon DynamoDB particiona automaticamente seus dados e trabalha com um número suficiente de servidores para satisfazer os requisitos de escala que você fornece. Em comparação, uma tabela no Amazon SimpleDB possui uma limitação de armazenamento total de 10 GB e está limitada à capacidade de solicitações que pode alcançar (normalmente inferior a 25 gravações/segundo); sendo você o responsável por administrar o particionamento e reparticionamento de dados em tabelas do SimpleDB adicionais, caso necessite de um dimensionamento adicional. Enquanto o SimpleDB possui limitações de escalabilidade, ele pode ser ideal para cargas de trabalho menores e que requerem flexibilidade de consulta. O Amazon SimpleDB indexa automaticamente todos os atributos de item e, desse modo, suporta flexibilidade de consulta em detrimento do desempenho e escala.

O post sobre o DynamoDB no blog de Werner Vogels, CTO da Amazon, oferece mais informações sobre a evolução da tecnologia de bancos de dados não relacionais na Amazon.

P: Quando devo usar o Amazon S3 em vez do Amazon DynamoDB?

O Amazon DynamoDB armazena dados estruturados, indexados por chave primária, e permite acesso de gravação e leitura de baixa latência a itens de 1 byte a 64KB. O Amazon S3 armazena BLOBs não estruturados e é adequado para armazenar grandes objetos de até 5 TB. A fim de otimizar seus custos com os serviços AWS, objetos ou arquivos grandes devem ser armazenados no Amazon S3, enquanto pequenos elementos de dados ou arquivo ponteiros (possivelmente para objetos do Amazon S3) devem ser salvos no Amazon DynamoDB.


P: O que é o modelo de dados?

O modelo de dados para o Amazon DynamoDB é o seguinte:

Tabela: uma tabela é uma coleção de itens de dados – assim como uma tabela em um banco de dados relacional é uma coleção de filas. Cada tabela pode ter um número infinito de itens de dados. O Amazon DynamoDB não tem esquema definido, ou seja, os itens de dados em uma tabela não precisam ter os mesmos atributos ou o mesmo número de atributos. Cada tabela deve ter uma chave primária. A chave primária pode ser um chave de atributo única ou uma chave de atributo "composta" que combina dois atributos. O(s) atributos(s) que você determinar como uma chave primária precisam existir para todos os itens, uma vez que as chaves primárias identificam exclusivamente cada item na tabela.

Item: um item é composto por uma chave primária ou composta e um número flexível de atributos. Não há um limite explícito para o número de atributos associados a um item individual, mas o tamanho agregado de um item, incluindo todos os nomes e valores de atributo, é de 64 KB.

Atributo: cada atributo associado a um item de dados é composto de um nome de atributo (p.ex. "Cor") e um valor ou conjunto de valores (p.ex. "Vermelho" ou "Vermelho, Amarelo, Verde"). Atributos individuais não possuem um limite de tamanho explícito, mas o valor total de um item (incluindo todos os nomes e valores de atributos) não pode exceder 64 KB.

P: Há um limite para o tamanho de um item?

O tamanho total de um item, incluindo nomes e valores de atributos, não pode exceder 64 KB.

P: Há um limite para o número de atributos que algum item pode ter?

Não há limite para o número de atributos que um item possa ter. No entanto, o tamanho total de um item, incluindo nomes e valores de atributos, não pode exceder 64 KB.

P: O que são APIs?

  • CreateTable – Cria uma tabela e especifica o índice primário usado para o acesso aos dados.
  • UpdateTable – Atualiza os valores da taxa de transferência provisionada para a tabela especificada.
  • DeleteTable – Exclui a tabela.
  • DescribeTable – Retorna as informações de tamanho, status e índice da tabela.
  • ListTables – Retorna uma lista de todas as tabelas associadas à conta e endpoint atuais.
  • PutItem – Cria um novo item, ou substitui um item antigo por um novo (incluindo todos os atributos). Se algum item existe em uma tabela específica com a mesma chave primária, o novo item substitui completamente o item já existente. Você também pode usar operadores condicionais para substituir um item somente se seus valores de atributo corresponderem às condições, ou inserir um novo item apenas se ele ainda não existir.
  • BatchWriteItem – Insere, substitui e exclui vários itens em várias tabelas em uma única solicitação, mas não em uma única transação. Suporta lotes de até 25 itens para Put ou Delete, com um tamanho total máximo de solicitação de 1 MB.
  • UpdateItem – Edita os atributos de um item existente. É possível usar operadores condicionais para executar uma atualização somente se os valores de atributo do item corresponderem a condições específicas.
  • DeleteItem – Exclui um item único em uma tabela por meio de uma chave primária. É possível usar operadores condicionais para excluir um item somente se os valores de atributo do item corresponderem a condições específicas.
  • GetItem – A operação GetItem retorna um conjunto de atributos para um item correspondente à chave primária. A operação GetItem fornece uma leitura eventualmente consistente por padrão. Caso seu aplicativo não aceite leituras eventualmente consistentes, use ConsistentRead.
  • BatchGetItem – A operação BatchGetItem retorna os atributos para vários itens de várias tabelas, usando suas chaves primárias. Uma resposta única tem o limite de tamanho de 1 MB e retorna a quantidade máxima de 100 itens. Compatível com consistência eventual e sólida.
  • Consulta – Obtém um ou mais itens da tabela usando a chave primária ou de um índice secundário usando a chave do índice. O escopo da consulta pode ser restrito usando operadores de comparação sobre o valor da chave de intervalo. Também é possível filtrar os resultados da consulta usando filtros nos atributos não chave. Compatível com consistência eventual e sólida. Uma resposta única tem um limite de tamanho de 1 MB.
  • Scan – Obtém um ou mais itens e atributos por meio de uma varredura completa pela tabela. Os itens retornados podem ser limitados por filtros especificados para um ou mais atributos. Esta API pode então ser usada para permitir uma consulta ad hoc de uma tabela em relação a atributos que não sejam a chave primária da tabela. Entretanto, uma vez que consiste em uma varredura sem índice, não deve ser usada para nenhum caso de uso de consulta do aplicativo que requeira um desempenho previsível. O conjunto de resultados de uma API Scan será eventualmente consistente. Você pode pensar que a API Scan é como se fosse um repetidor (iterator). Uma vez que o tamanho agregado de itens varridos para uma determinada solicitação de API Scan exceda 1 MB de limite, tal solicitação será concluída e os resultados produzidos serão retornados junto com a LastEvaluatedKey (para continuar a varredura em uma operação posterior).

P: Que tipos de dados o DynamoDB suporta?

O Amazon DynamoDB suporta três tipos de dados de escala: número, sequência de caracteres e binário. Além disso, o Amazon DynamoDB suporta tipos de multivalores: conjunto de números, conjunto de sequência de caracteres e conjunto binário.


P: Há algum limite para o volume de dados que eu posso armazenar no Amazon DynamoDB?

Não. Você pode armazenar qualquer quantidade de armazenamento que seja colocado em uma tabela do Amazon DynamoDB. À medida que o tamanho de seu conjunto de dados aumenta, o Amazon DynamoDB distribuirá automaticamente seus dados entre recursos de máquinas suficientes para atender às suas solicitações de armazenamento.

P: Há um limite para a taxa de transferência que posso obter com uma única tabela?

Não, você pode aumentar a taxa de transferência que foi provisionada para a tabela usando a API UpdateTable ou no AWS Management Console. O DynamoDB consegue operar em escala massiva e não há um limite hipotético para o máximo de taxa de transferência que você pode alcançar. O DynamoDB divide automaticamente sua tabela entre vários particionamentos, onde cada particionamento é uma unidade de computação paralela independente. O DynamoDB pode alcançar valores de taxa de transferência cada vez mais altos ao adicionar mais particionamentos.

Caso queira exceder os valores de taxa de transferência em 10.000 gravações/segundo ou 10.000 leituras/segundo, você deve primeiro entrar em contato com a Amazon preenchendo este formulário.

P: O Amazon DynamoDB permanece disponível quando solicito a redução ou o aumento de escala alterando a taxa de transferência provisionada?

Sim. O Amazon DynamoDB é projetado para aumentar ou diminuir sua taxa de transferência provisionada enquanto permanece disponível.

P: Preciso administrar o particionamento do lado do cliente além do Amazon DynamoDB?

Não. O Amazon DynamoDB elimina a necessidade de particionamento das tabelas para escalabilidade de taxa de transferência.

P: Qual o nível de alta disponibilidade do Amazon DynamoDB?

O serviço é executado nos centros de dados comprovados e de alta disponibilidade da Amazon. O serviço replica os dados através de três recursos em uma região da AWS para fornecer tolerância a falhas no caso da falha de um servidor ou interrupção da zona de disponibilidade.

P: Como o Amazon DynamoDB alcança maior durabilidade e tempo de atividade?

Para alcançar alto tempo de atividade e durabilidade, o Amazon DynamoDB replica simultaneamente os dados em três instalações dentro de uma região da AWS.


P: O que são índices secundários globais?

Os índices secundários globais são índices que contêm chaves de hash ou de hash e intervalo que podem ser diferentes das chaves na tabela na qual o índice é baseado.

Para o acesso eficiente aos dados de uma tabela, o Amazon DynamoDB cria e mantém índices para os atributos da chave primária. Isso permite aos aplicativos rapidamente consultar dados especificando valores de chave primária. Porém, muitos aplicativos podem se beneficiar com a disponibilização de uma ou mais chaves secundárias (ou alternativas) que permitam o acesso eficiente aos dados com atributos diferentes da chave primária. Para fazer isso, você pode criar um ou mais índices secundários em uma tabela e enviar requisições de consulta contra estes índices.

O Amazon DynamoDB oferece suporte a dois tipos de índices secundários:

  • Índice secundário local: um índice que tem a mesma chave de hash que a tabela, mas uma chave de intervalo diferente. Um índice secundário local é "local" no sentido de que o escopo de todas as partições do índice secundário local é a partição da tabela com a mesma chave de hash.
  • Índice secundário global: um índice com uma chave de hash ou de hash e intervalo que pode ser diferente das contidas na tabela. Um índice secundário global é considerado "global" porque as consultas ao índice podem abranger todos os itens da tabela, em todas as partições. 

Os índices secundários são automaticamente mantidos pelo Amazon DynamoDB como objetos esparsos. Os itens só aparecerão no índice se existirem na tabela onde o índice está definido. Isso torna as consultas ao índice muito eficientes, porque o número de itens contidos no índice geralmente será significativamente menor que o número de itens contidos na tabela.

Índices secundários globais dão suporte a atributos não únicos, aumentando a flexibilidade de consulta ao permitir consultas contra quaisquer atributos não chave da tabela.

Considere um aplicativo de jogo que guarda a informação dos jogadores em uma tabela do DynamoDB na qual a chave primária consiste em IdUsuario (hash) e TituloJogo (intervalo). Os itens têm atributos chamados PontuacaoMaxima, DataHora, CEP e outros. No momento de criação da tabela, o DynamoDB fornece um índice implícito (índice primário) na chave primária que permite consultas eficientes às pontuações máximas de um usuário específico em todos os jogos.

Porém, se o aplicativo requer pontuações máximas de jogadores para um único jogo, seria ineficiente usar este índice primário e isto iria requerer uma varredura em toda a tabela. Ao invés disso, um índice secundário global composto por TituloJogo como elemento da chave de hash e PontuacaoMaxima como elemento da chave de intervalo permitiriam ao aplicativo consultar rapidamente as pontuações máximas de um jogo.

Um GSI não precisa ter um elemento de chave de intervalo. Por exemplo, você poderia ter um GSI com uma chave que tem apenas o elemento de hash TituloJogo. No exemplo abaixo, o GSI não tem nenhum atributo projetado, então ele simplesmente retornará todos os itens (identificados pela chave primária) que têm um atributo igual ao TituloJogo que está sendo consultado.

P: Quando eu devo usar índices secundários globais?

Índices secundários globais são particularmente úteis para acompanhar relacionamentos entre atributos que tenham muitos valores diferentes. Por exemplo, você poderia criar uma tabela do DynamoDB com IdCliente como chave de hash primária da tabela e CEP como chave de hash do índice secundário global, já que há muitos CEPs e você provavelmente terá muitos clientes. Usando a chave primária, você poderia rapidamente consultar o registro de qualquer cliente. Usando o índice secundário global, você poderia consultar eficientemente todos os clientes localizados em um determinado CEP.

Para garantir que você use ao máximo a capacidade do seu índice secundário global, veja a documentação de práticas recomendadas em cargas de trabalho uniformes.

P: Como eu crio um índice secundário global em uma tabela DynamoDB?

Todos os GSIs de uma tabela devem ser especificados no momento da criação da tabela. Neste momento, não é possível adicionar um GSI após a criação da tabela. Para um detalhamento maior das etapas de criação de uma tabela e seus índices, veja aqui. Você pode criar até 5 índices secundários globais por tabela.

P: O DynamoDB Local dá suporte a índices secundários globais?

Sim. O DynamoDB Local é uma versão off-line do DynamoDB que é útil para o desenvolvimento e teste de aplicativos baseados no DynamoDB. O download da última versão do DynamoDB Local pode ser feito aqui.

P: O que são atributos projetados?

Os dados em um índice secundário consistem de atributos que são projetados, ou copiados, da tabela para o índice. Ao criar um índice secundário, você define uma chave alternativa para o índice, juntamente com outros atributos quaisquer que quer que sejam projetados no índice. O Amazon DynamoDB copia estes atributos para o índice, juntamente com os atributos da chave primária da tabela. Depois disso, você pode consultar o índice da mesma forma que consultaria uma tabela.

P: Uma chave de índice secundário global pode ser definida por atributos não únicos?

Sim. Diferentemente da chave primária em uma tabela, um índice GSI não requer que os atributos indexados sejam únicos. Por exemplo, o GSI em TituloJogo poderia indexar todos os itens que acompanham pontuações de usuários para todos os jogos. Nesse exemplo, esse GSI pode ser consultado para retornar todos os usuários que jogaram o jogo "JogoDaVelha".

P: Quais as diferenças entre índices secundários globais e índices secundários locais?

Os índices secundários globais e locais aprimoram a flexibilidade da consulta. Um LSI é vinculado a um valor específico de hash de chave primária, enquanto um GSI abrange todos os valores de hash de chave primária. Como itens que têm o mesmo valor de hash de chave primária compartilham a mesma partição no DynamoDB, o índice secundário local apenas abrange itens que estão armazenados juntos (na mesma partição). Portanto, a finalidade do LSI é consultar itens que têm o mesmo valor de hash de chave primária mas uma chave de intervalo diferente. Por exemplo, considere uma tabela DynamoDB que monitora Pedidos de clientes, onde o IdCliente é a chave primária.

Um LSI no HorarioPedido permite consultas eficientes que retornam os itens pedidos mais recentes para um cliente em específico.

Um GSI, em contraste, não se restringe a itens com o mesmo valor de hash de chave primária. Em vez disso, ele abrange todos os itens da tabela, da mesma forma que o índice primário implícito. Na tabela acima, um GSI no IdProduto pode ser usado para consultas eficientes a todos os pedidos de um produto em específico. Note que, neste caso, nenhuma chave de intervalo de GSI é especificada, e mesmo que hajam vários pedidos com o mesmo IdProduto, eles serão armazenados como itens separados no GSI.

Para garantir que os dados da tabela e do índice sejam armazenados na mesma partição, os LSIs limitam [MC4] o tamanho total de todos os elementos (tabelas e índices) a 10 GB por valor de hash de chave. Os GSIs não impõem armazenamento conjunto e não têm esta restrição.

Ao escrever em uma tabela, o DynamoDB automaticamente atualiza todos os LSIs afetados. Atualizações em quaisquer GSIs definidos na tabela, em contraste, são eventualmente consistentes.

Os LSIs permitem à API de consultas retornar atributos que não são parte da lista de projeção. Esse comportamento não é suportado pelos GSIs.

P: Como os índices secundários globais funcionam?

O comportamento de um GSI é similar de várias formas ao de uma tabela do DynamoDB. Você pode consultar um GSI usando seu elemento de chave de hash, com filtros condicionais no elemento de chave de intervalo. Porém, diferentemente de uma chave primária de tabela do DynamoDB, que deve ser única, uma chave de GSI pode ser a mesma para vários itens. Se existem vários itens com a mesma chave de GSI, eles são tratados como itens diferentes no GSI, e uma consulta no GSI retornará todos eles como itens individuais. Internamente, o DynamoDB garantirá que o conteúdo do GSI é atualizado de forma apropriada conforme itens são adicionados, removidos ou atualizados.

O DynamoDB armazena os atributos projetados de um GSI na estrutura de dados do GSI, junto à sua chave e às chaves primárias dos itens abrangidos. Os GSIs consomem armazenamento de itens projetados que existem na tabela-fonte. Isso permite o envio de consultas contra o GSI ao invés da tabela, aumentando a flexibilidade de consulta e aprimorando a distribuição de carga de trabalho. Os atributos que são parte de um item em uma tabela, mas não parte da chave do GSI, ou da chave primária da tabela ou atributos projetados, não são portanto retornados ao se consultar o índice GSI. As aplicações que precisam de dados adicionais da tabela após consultarem o GSI podem consultar a chave primária do GSI e então usar as APIs GetItem ou BatchGetItem para recuperar os atributos da tabela desejados. Como os GSIs são eventualmente consistentes, aplicativos que utilizam esse padrão devem acomodar a exclusão de itens (da tabela) entre chamadas ao GSI e ao GetItem ou BatchItem.

O DynamoDB trata automaticamente adições, atualizações e exclusões de itens em um GSI quando as alterações correspondentes são realizadas na tabela. Quando um item (com atributos de chave do GSI) é adicionado à tabela, o DynamoDB atualiza o GSI assincronamente para adicionar o novo item. Similarmente, quando um item é excluído da tabela, o DynamoDB remove o item do GSI impactado.

P: Eu posso criar índices secundários globais para tabelas baseadas em hash e tabelas com schema de intervalo de hash?

Sim, você pode criar um índice secundário global independentemente do tipo de chave primária da tabela do DynamoDB. A tabela pode ter apenas uma chave de hash primária ou um hash primário e uma chave de intervalo.

P: Qual é o modelo de consistência para índices secundários globais?

Os GSIs oferecem suporte à consistência eventual. Quando itens são inseridos ou atualizados em uma tabela, os GSIs não são atualizados de forma síncrona. Em condições normais de operação, uma operação de escrita em um índice secundário global será propagada em uma fração de segundo. Em cenários improváveis de falha, esperas maiores poderão ocorrer. Por isso, a lógica do seu aplicativo deve ser capaz de tratar resultados de consulta de GSI que possam estar potencialmente desatualizados. Note que este é o mesmo comportamento exibido por outras APIs do DynamoDB que oferecem suporte a leituras eventualmente consistentes.

Considere uma tabela que acompanha pontuações máximas em que cada item tem os atributos IdUsuario, TituloJogo e PontuacaoMaxima. A chave de hash primária é IdUsuario e a chave de intervalo primária é TituloJogo. Se o aplicativo adicionar um item representando uma nova pontuação máxima para o TituloJogo "JogoDaVelha" e IdUsuario "GAMER123", e subsequentemente consultar o GSI, é possível que a nova pontuação máxima não conste ainda no resultado da consulta. Porém, uma vez que a propagação do GSI tenha sido terminada, o novo item começará a aparecer nas consultas ao GSI.

P: Eu posso provisionar taxa de transferência separadamente para a tabela e para cada índice secundário global?

Sim. Os GSIs gerenciam taxa de transferência de forma independente da tabela em que são baseados. Você deve especificar explicitamente a taxa de transferência provisionada para a tabela e para cada GSI no momento da criação. Você pode usar o Create Table Wizard do DynamoDB Console, que pode assisti-lo na distribuição de sua taxa de transferência total entre suas tabelas e índices.

Dependendo do seu aplicativo, a carga de trabalho de uma requisição a um GSI pode ficar significativamente diferente da requisição a uma tabela ou outros GSIs. Alguns cenários que mostram isso são dados abaixo:

  • Um GSI que contenha apenas uma pequena parte dos itens da tabela precisa de uma taxa de escrita muito menor comparado com a tabela.
  • Um GSI que é usado para pesquisas de itens infrequentes precisa de uma taxa de leitura muito menor comparado com a tabela.
  • Um GSI usado por uma tarefa de segundo plano de leitura pesada pode precisar de uma taxa de leitura alta por algumas horas por dia.

Conforme suas necessidades evoluem, você pode alterar a taxa de transferência provisionada do GSI, independentemente da taxa de transferência provisionada da tabela.

Considere uma tabela do DynamoDB com um GSI que projeta todos os atributos e tem a chave do GSI presente em 50% dos itens. Nesse caso, as unidades de capacidade de escrita provisionadas na GSI devem ser estabelecidas em ao menos 50% das unidades de capacidade de escrita provisionadas na tabela. Usando uma abordagem similar a taxa de leitura do GSI pode ser estimada. Veja a Documentação de GSI do DynamoDB para mais detalhes.

P: Como a adição de um índice secundário global impacta a taxa de transferência e armazenamento provisionados para uma tabela?

De forma similar a uma tabela do DynamoDB, um GSI consome taxa de transferência provisionada quando leituras ou escritas são realizadas nele. Uma operação de escrita que adiciona ou atualiza um item em um GSI consumirá unidades de capacidade de escrita baseado no tamanho da atualização. A capacidade consumida pela operação de escrita no GSI é adicional à capacidade necessária para atualizar o item na tabela.

Note que se você adicionar, excluir ou atualizar um item em uma tabela do DynamoDB, e se isso não resultar em uma mudança em um GSI, o GSI não consumirá nenhuma unidade de capacidade de escrita. Isso pode acontecer quando um item sem nenhum atributo de chave de GSI é adicionado à tabela do DynamoDB ou um item é atualizado sem mudar nenhuma chave de GSI ou atributos projetados.

Uma consulta ao GSI consome unidades de capacidade de leitura baseado no tamanho dos itens examinados pela consulta.

Os custos de armazenamento de um GSI são baseados no número total de bytes armazenados naquele GSI. Isso inclui a chave do GSI e atributos e valores projetados, mais 100 bytes para fins de indexação.

P: O DynamoDB pode controlar as escritas do meu aplicativo em uma tabela por causa da taxa de transferência provisionada em um GSI?

Devido ao fato de que algumas ou todas as operações de escrita realizadas em uma tabela do DynamoDB resultam em operações de escrita nos GSIs relacionados, é possível que a taxa de transferência provisionada em um GSI possa ser esgotada. Em tal cenário, as próximas operações de escrita feitas na tabela serão controladas. Isso pode ocorrer mesmo se a tabela tiver unidades de capacidade de escrita disponíveis.

P: Com que frequência posso alterar a taxa de transferência provisionada a nível de índice?

As tabelas com GSIs têm os mesmos limites diários de quantidade de operações de alteração de taxa de transferência que as tabelas normais.

P: Como sou cobrado pelo índice secundário global do DynamoDB?

Você é cobrado pela taxa de transferência provisionada agregada de uma tabela e seus GSIs por hora. Além disso, você é cobrado pelo armazenamento utilizado pelo GSI assim como taxas padrão de transferência (externa) de dados. Caso queira fazer alterações na capacidade de taxa de transferência provisionada do seu GSI, você pode usar o DynamoDB Console ou a API UpdateTable.

P: Eu posso especificar qual índice secundário global deve ser usado para uma consulta?

Sim. Além dos parâmetros comuns de consulta, um comando Query de GSI inclui o nome do GSI a ser operado de forma explícita. Note que uma consulta pode usar somente um GSI.

P: Quais chamadas de API são suportadas por um índice secundário global?

As chamadas de API suportadas por um GSI são Query e Scan. Uma operação de Query pesquisa somente valores de atributo de chave de índice e oferece suporte a um subconjunto dos operadores de comparação. Pelo fato de GSIs serem atualizados assincronamente, o parâmetro ConsistentRead não pode ser usado na consulta. Veja aqui mais detalhes sobre o uso de consultas e varreduras em GSIs.

P: Como modifico ou excluo um índice secundário global após a criação da tabela?

Índices não podem ser criados, modificados ou excluídos após a tabela ser criada.

P: Os atributos de chave de GSI são requeridos em todos os itens de uma tabela do DynamoDB?

Não. Os GSIs são índices esparsos. Diferentemente do requerimento para uma chave primária, um item em uma tabela DynamoDB não precisa conter nenhuma das chaves do GSI. Se uma chave de GSI contém tanto elementos de hash quanto de intervalo, e um item da tabela omite algum deles, então aquele item não será indexado pelo GSI correspondente. Em tais casos, um GSI pode ser bastante útil na localização eficiente de itens que tenham um atributo incomum.

P: Eu posso recuperar todos os atributos de uma tabela do DynamoDB a partir de um índice secundário global?

Uma consulta em um GSI pode retornar somente atributos que foram especificados para serem incluídos no GSI no momento de sua criação. Os atributos incluídos no GSI são aqueles que são projetados por padrão, como os atributos de chave do GSI e os atributos de chave primária da tabela, e aqueles que o usuário especificou para serem projetados. Por este motivo, uma consulta a um GSI não retornará atributos dos itens que são parte da tabela, mas não estão incluídos no GSI. Um GSI que especifique todos os atributos como atributos projetados pode ser usado para recuperar quaisquer atributos da tabela. Veja aqui a documentação sobre o uso de GSIs para consultas.

P: Como posso listar GSIs associados a uma tabela?

A API DescribeTable fornece informações detalhadas sobre índices secundários globais em uma tabela.

P: Que tipos de dados podem ser indexados?

Todos os tipos de dados escalares podem ser parte de uma chave de GSI (atributos de hash e intervalo). Tipos de conjunto não podem ser parte de uma chave de GSI (atributos de hash ou intervalo).

P: Índices com atributos compostos são possíveis?

Não. Mas você pode concatenar atributos em uma string e usá-la como chave.

P: Que tipos de dados podem compor os atributos projetados em um GSI?

Você pode especificar atributos com quaisquer tipos de dados (incluindo tipos de conjunto) para serem projetados em um GSI.

P: Quais são algumas considerações de escalabilidade dos GSIs?

Considerações de desempenho da chave primária de uma tabela do DynamoDB também se aplicam a chaves de GSI. Um GSI assume um padrão de acesso relativamente aleatório em todas as suas chaves. Para aproveitar o máximo da taxa de transferência provisionada do índice secundário, você deve selecionar um elemento de hash de chave de GSI que tenha um grande número de valores distintos, e um elemento de chave de intervalo que seja requisitado de forma razoavelmente uniforme e o mais aleatoriamente possível.

P: Quais métricas novas serão disponibilizadas pelo CloudWatch para índices secundários globais?

As tabelas com GSI irão fornecer métricas agregadas da tabela e dos GSIs, assim como métricas detalhadas da tabela e de cada GSI.

Relatórios individuais para cada GSI irão dar suporte a um subconjunto das métricas do CloudWatch que são suportadas por tabelas. Dentre eles estão:

  • Capacidade de Leitura (Capacidade Provisionada de Leitura, Capacidade Consumida de Leitura)
  • Capacidade de Escrita (Capacidade Provisionada de Escrita, Capacidade Consumida de Escrita)
  • Eventos de leitura controlados
  • Eventos de escrita controlados

Para mais detalhes sobre as métricas suportadas por tabelas e índices do DynamoDB, veja aqui.

P: Posso fazer escalabilidade automática de minhas tabelas e índices no DynamoDB?

Apesar de não ser uma função nativa, há bibliotecas recomendadas de terceiros que estão localizadas na seção Recursos do desenvolvedor da página do DynamoDB.


P: O que são índices secundários locais?

Os índices secundários locais permitem que algumas consultas comuns executem com muito mais rapidez e economia, evitando a recuperação de um grande número de itens e a filtragem dos resultados. Isso significa que seus aplicativos podem confiar em consultas mais flexíveis baseadas em uma maior variedade de atributos.

Antes da disponibilização dos índices secundários locais, se você quisesse encontrar itens específicos em um bucket de chaves de hash (itens que compartilham a mesma chave de hash), o DynamoDB tinha de buscar todos os objetos que compartilhavam uma única chave de hash e filtrar os resultados de acordo com a consulta. Por exemplo, considere um aplicativo de comércio eletrônico que armazena dados de pedidos de cliente em uma tabela do DynamoDB com um schema de faixa de hash de código do cliente e carimbo de data/hora. Sem o LSI, para encontrar uma resposta para a pergunta "Exibir todos os pedidos feitos pelo cliente X com data de remessa nos últimos 30 dias, classificados pela data de remessa", era necessário usar a API de consultas para recuperar todos os objetos com a chave de hash "X", classificar os resultados por data de remessa e então filtrar os registros mais antigos.

Os índices secundários locais simplificam essa experiência. Agora, é possível criar um índice para o atributo "data de remessa" e executar essa consulta com eficiência, recuperando apenas os itens necessários. Isso reduz consideravelmente a latência e o custo das consultas, pois apenas os itens que atendem aos seus critérios específicos serão recuperados. Além disso, o modelo de programação do seu aplicativo é simplificado, já que não é mais necessário escrever lógica no cliente para filtrar os resultados. Denominamos esse novo índice secundário um índice secundário "local" porque é usando juntamente com a chave de hash, permitindo dessa forma pesquisar localmente dentro de um bucket de chave de hash. Assim, enquanto que anteriormente somente era possível pesquisar usando a chave de hash e a faixa de hash, agora também é possível pesquisar usando um índice secundário em vez da chave de faixa, aumentando o número de atributos que podem ser usados para consultas executadas com eficiência.

As cópias redundantes dos atributos de dados são copiadas para os índices secundários locais definidos por você. Esses atributos incluem a chave de hash da tabela e da faixa, além da chave de faixa alternativa que você definiu. Também é possível armazenar dados redundantes de outros atributos de dados no índice secundário local, permitindo o acesso a esses dados sem necessidade de acessar a própria tabela.

Os índices secundários locais não são adequados para todos os aplicativos. Eles introduzem algumas restrições quanto ao volume de dados que pode ser armazenado em um único valor de chave de hash. Para obter mais informações, consulte as perguntas frequentes abaixo sobre coleções de itens.

P: O que são projeções?

O conjunto de atributos copiado para um índice secundário local é denominado uma projeção. A projeção determina os atributos que você poderá recuperar com maior eficiência. Quando você consulta um índice secundário local, o Amazon DynamoDB pode acessar qualquer um dos atributos projetados com as mesmas características de desempenho de atributos residentes em uma tabela própria. Se você precisa recuperar qualquer atributo não projetado, o Amazon DynamoDB automaticamente buscará esses atributos na tabela.

Ao definir um índice secundário local, é necessário especificar os atributos que serão projetados no índice. No mínimo, cada entrada de índice consiste em: (1) o valor de chave de hash a tabela, (2) um atributo para servir como a chave de faixa do índice e (3) o valor da chave de faixa da tabela.

Além dessas informações mínimas, você também pode escolher uma lista especificada pelo usuário ou outros atributos não chave para serem projetados no índice. Você pode até optar por projetar todos os atributos no índice. Neste caso, o índice replica os mesmos dados da própria tabela, mas com os dados organizados pela chave de faixa alternativa que você especificou.

P: Como posso criar um LSI?

O LSI deve ser criado no momento da criação da tabela. No momento, não é possível adicionar um LSI após a criação da tabela. Para criar um LSI, especifique os dois parâmetros abaixo:

Indexed Range key – o atributo que será a base para a indexação e para as consultas.

Projected Attributes – a lista de atributos da tabela que serão copiados diretamente para o índice secundário local para que possam ser retornados com maior rapidez, sem necessidade de recuperar dados do índice primário, que contém todos os itens da tabela. Sem atributos projetados, o índice secundário local contém apenas chaves dos índices primário e secundário.

P: Qual é o modelo de consistência do LSI?

Os índices secundários locais são atualizados automaticamente quando o índice primário é atualizado. De forma semelhante às leituras de um índice primário, o LSI oferece suporte às opções de leitura fortemente e eventualmente consistente.

P: Os índices secundários locais contêm referências a todos os itens da tabela?

Não necessariamente. Os índices secundários locais referenciam apenas os itens que contêm a chave de faixa indexada especificada para cada LSI. O schema flexível do DynamoDB permite que nem todos os itens necessariamente contenham todos os atributos.

Isso significa que o índice secundário local pode ser preenchido de forma esparsa, quando comparado ao índice primário. Como os índices secundários locais são esparsos, oferecem suporte eficiente a consultas de atributos incomuns.

Por exemplo, no exemplo de pedidos descrito acima, um cliente pode ter alguns atributos adicionais em um item, incluídos apenas se o pedido for cancelado (como CanceledDateTime e CanceledReason). Para consultas relacionadas a itens cancelados, um índice secundário local para qualquer um desses atributos seria eficiente, pois os itens referenciados pelo índice seriam apenas os que têm esse atributo presente.

P: Como faço para consultar índices secundários locais?

Os índices secundários locais somente podem ser consultados usando a API de consultas.

Para consultar um índice secundário local, referencie explicitamente esse índice além do nome da tabela que deseja consultar. Você deve especificar o nome e o valor do atributo de hash do índice. Opcionalmente, é possível especificar uma condição para o atributo de faixa de chaves do índice.

A sua consulta pode recuperar atributos não projetados armazenados no índice primário executando uma operação de busca de tabela, incorrendo no custo da leitura de unidades adicionais de capacidade de leitura.

As consultas que usam índices secundários locais oferecem suporte a leituras fortemente consistentes e eventualmente consistentes.

P: Como faço para criar índices secundários locais?

Os índices secundários locais devem ser definidos no momento da criação da tabela. O índice primário da tabela deve usar uma chave composta de faixa de hash.

P: Posso adicionar índices secundários locais a uma tabela existente?

No momento, não é possível adicionar índices secundários locais a tabelas existentes. Estamos trabalhando para adicionar esse recurso, que será lançado futuramente. Quando você cria uma tabela com índice secundário local, pode decidir criar um índice secundário local para uso futuro definido um elemento de chave de faixa não usado no momento. Como o índice secundário local é esparso, esse índice não custa nada até que você decida utilizá-lo.

P: Quantos índices secundários locais posso criar em uma tabela?

Cada tabela pode ter até cinco índices secundários locais.

P: Quantos atributos não chave projetados posso criar em uma tabela?

Cada tabela pode ter até 20 atributos não chave projetados em todos os índices secundários locais dentro da tabela. Em cada índice, também é possível especificar que todos os atributos não chave do índice primário são projetados.

P: Posso modificar um índice após sua criação?

Não é possível modificar um índice após a criação. Estamos trabalhando para adicionar esse recurso no futuro.

P: Posso excluir índices secundários locais?

No momento, índices secundários locais não podem ser removidos após a criação de uma tabela. Naturalmente, eles são excluídos se você decidir excluir toda a tabela. Estamos trabalhando para adicionar esse recurso, que será lançado futuramente.

P: Como os índices secundários locais consomem a capacidade provisionada?

Você não precisa provisionar capacidade explicitamente para um índice secundário local. O índice consome capacidade provisionada como parte da tabela à qual está associado.

As leituras e gravações de LSIs consome capacidade de acordo com a fórmula padrão de 1 unidade por 1 KB de dados lidos ou gravados a cada segundo, com as seguintes diferenças:

Quando as gravações contêm dados que são relevantes a um ou mais índices secundários locais, essas gravações são espelhadas nos índices secundários locais apropriados. Nesses casos, a capacidade de gravação será consumida para a própria tabela e uma capacidade de gravação adicional será consumida para cada LSI relevante.

As atualizações que substituem um item existente podem resultar em duas operações – exclusão e inserção – e, portanto, consome unidades adicionais de capacidade de gravação por 1 KB de dados.

Quando uma consulta de leitura solicita atributos não projetados no LSI, o DynamoDB buscará esses atributos no índice primário. Essa solicitação GetItem implícita consome uma unidade de capacidade de leitura por 1 KB de dados de item buscados.

P: Quanto armazenamento é consumido pelos índices secundários locais?

Os índices secundários locais consomem armazenamento para o nome e valor do atributo das chaves primárias e de índice de cada LSI, para todos os atributos não chave projetados, e mais 100 bytes por item refletido no LSI.

P: Que tipos de dados podem ser indexados?

Todos os tipos de dados escalares (Number, String, Binary) podem ser usados para o elemento de chave da faixa da chave do índice secundário local. Não é possível usar tipos definidos.

P: Que tipos de dados podem ser projetados em um índice secundário local?

Todos os tipos de dados (incluindo os tipos definidos) podem ser projetados em um índice secundário local.

P: O que são as coleções de itens e como se relacionam ao LSI?

No Amazon DynamoDB, uma coleção de itens é qualquer grupo de itens com a mesma chave de hash em uma tabela e em todos os seus índices secundários locais. Sistemas de bancos de dados relacionais tradicionais particionados (ou particionados horizontalmente) acessam esses particionamentos horizontais ou partições referenciando todos os itens ou linhas de banco de dados armazenados com uma determinada chave de hash.

As coleções de itens são criadas e mantidas automaticamente para cada tabela que inclui índices secundários locais. O DynamoDB armazena cada coleção de itens em uma única partição de disco.

P: Há limites para o tamanho de uma coleção de itens?

Cada coleção de itens no Amazon DynamoDB está sujeita ao limite de tamanho máximo de 10 gigabytes. Para qualquer valor de chave de hash distinto, a soma dos tamanhos dos itens na tabela mais a soma dos tamanhos do item em todos os índices secundários locais da tabela não deve exceder 10 GB.

O limite de 10 GB para as coleções de itens não se aplica a tabelas sem índices secundários locais, mas apenas a tabelas que têm um ou mais índices secundários locais.

Embora o tamanho das coleções de itens individuais seja limitado, o tamanho do armazenamento de toda a tabela com os índices secundários locais não é limitado. O tamanho total de uma tabela indexada no Amazon DynamoDB é efetivamente ilimitado, desde que o tamanho de armazenamento total (tabela e índices) de qualquer chave de hash não exceda o limite de 10 GB.

P: Como posso controlar o tamanho de uma coleção de itens?

As APIs de gravação do DynamoDB (PutItem, UpdateItem, DeleteItem e BatchWriteItem) incluem uma opção que permite que a resposta da API inclua uma estimativa do tamanho da coleção de itens relevante. Ela inclui uma estimativa inferior e superior para os dados de uma determinada coleção de itens, medida em gigabytes.

Recomendamos que você adapte o seu aplicativo para monitorar os tamanhos das coleções de itens. Os aplicativos devem examinar as respostas das APIs relativas ao tamanho da coleção de itens e gerar uma mensagem de erro sempre que uma coleção de itens exceder um limite definido pelo usuário (por exemplo, 8 GB). Esse sistema de aviso antecipado alertará você se uma coleção de itens estiver crescendo muito, dando tempo suficiente para resolver o problema.

P: O que acontece se eu exceder o limite de 10 GB para uma coleção de itens?

Se uma determinada coleção de itens excede o limite de 10 GB, você não conseguirá gravar novos itens ou aumentar o tamanho de itens existentes para essa determinada chave de hash. As operações de leitura e gravação que reduzem o tamanho da coleção de itens continuarão sendo permitidas. As outras coleções de itens da tabela não serão afetadas.

Para resolver esse problema, você pode remover itens ou reduzir tamanhos de item na coleção que excedeu os 10 GB. Como alternativa, você pode inserir novos itens usando um novo valor de chave de hash para contornar esse problema. Se a sua tabela incluir dados históricos acessados com pouca frequência, considere o arquivamento de dados históricos no Amazon S3, no Amazon Glacier ou em outro armazenamento de dados.


P: O que é o controle de acesso minucioso do DynamoDB?

O controle de acesso minucioso (FGAC, Fine Grained Access Control) oferece ao proprietário de tabelas do DynamoDB um alto grau de controle sobre os dados nas tabelas. Especificamente, o proprietário da tabela pode especificar quem (chamador) pode acessar quais itens ou atributos da tabela e executar quais ações (recursos de leitura e gravação). O FGAC é usado juntamente com o AWS Identity and Access Management (IAM), que gerencia as credenciais de segurança e as permissões associadas.

P: Quais são os casos de uso comuns para o FGAC do DynamoDB?

O FGAC pode beneficiar todos os aplicativos que rastreiam informações em uma tabela do DynamoDB, onde o usuário final (ou um cliente de aplicativo atuando em nome de um usuário final) deseja ler ou modificar a tabela diretamente, sem interferência de um serviço de camada intermediária. Por exemplo, um desenvolvedor de um aplicativo móvel denominado Acme pode usar o FGAC para rastrear a pontuação máxima de todos os usuários do Acme em uma tabela do DynamoDB. O FGAC permite que o cliente do aplicativo modifique apenas a pontuação máxima do usuário que está executando o aplicativo no momento.

P: Sem o FGAC, como um desenvolvedor pode conseguir controlar o acesso no nível de item?

Para conseguir esse nível de controle sem o FGAC, o desenvolvedor tem de optar entre algumas abordagens potencialmente onerosas. Algumas delas são:

  1. Proxy: o cliente do aplicativo envia uma solicitação a um proxy de intermediação que executa a autenticação e a autorização. Essa solução aumenta a complexidade da arquitetura do sistema e pode resultar em um maior custo total de propriedade (TCO).
  2. Tabela por cliente: uma tabela separada é designada para cada cliente do aplicativo. Como os clientes do aplicativo acessam tabelas diferentes, estariam protegidos uns dos outros. Essa solução pode levar o desenvolvedor a criar milhões de tabelas, tornando o gerenciamento do banco de dados extremamente complicado.
  3. Token incorporado por cliente: um token secreto é incorporado no cliente do aplicativo. A desvantagem dessa solução é a dificuldade para alterar o token e para lidar com o seu impacto nos dados armazenados. Aqui, a chave dos itens que podem ser acessados pelo cliente conteria o token secreto.

P: Como funciona o FGAC do DynamoDB?

Com o FGAC, um aplicativo solicita um token de segurança que autoriza o aplicativo a acessar apenas itens específicos em uma tabela específica do DynamoDB. Com esse token, o agente do aplicativo do usuário final pode fazer solicitações diretamente ao DynamoDB. Ao receber a solicitação, as credenciais da solicitação recebida são avaliadas pelo DynamoDB, que usará o IAM para autenticar a solicitação e determinar os recursos permitidos para o usuário. Se a solicitação do usuário não for permitida, o FGAC evitará que os dados sejam acessados.

P: Quanto custa o FGAC do DynamoDB?

Não há custo adicional para o uso do FGAC. Como sempre, você paga apenas pela taxa de transferência e armazenamento provisionados associados à tabela do DynamoDB.

P: Como faço para começar?

Consulte a seção Controle de acesso minucioso do DynamoDB Developer Guide para saber como criar uma política de acesso, criar uma função IAM para o aplicativo (p.ex., uma função denominada AcmeFacebookUsers para um código de aplicativo 34567 do Facebook) e atribuir a política de acesso à função. A política de confiança da função determina quais provedores de identidade são aceitos (p.ex., Login with Amazon, Facebook ou Google) e a política de acesso descreve quais recursos da AWS podem ser acessados (p.ex., uma tabela do DynamoDB). Usando a função o aplicativo agora pode obter credenciais temporárias para o DynamoDB chamando a API AssumeRoleWithIdentityRequest API do AWS Security Token Service (STS).

P: Como permito que usuário consultem um índice secundário local, mas evito que eles causem um acesso de tabela para recuperar atributos não projetados?

Algumas operações de consulta em um índice secundário local podem ser mais caras que as outras se solicitarem atributos que não estão projetados em um índice. Você pode restringir essas operações de "acesso" potencialmente caras limitando as permissões a somente atributos projetados usando a chave de contexto "dynamodb:Attributes".

P: Como evito que os usuários acessem atributos específicos?

A abordagem recomendada para evitar acesso a atributos específicos é seguir o princípio do menor privilégio, e permitir acesso apenas a atributos específicos.

Como alternativa, você pode usar uma política de Recusar para especificar atributos não permitidos. No entanto, isso não é recomendado pelos seguintes motivos:

  1. Com uma política de Recusar, o usuário pode descobrir os nomes dos atributos ocultos emitindo solicitações repetidas para todos os nomes de atributos possíveis até que, por fim, o acesso seja recusado.
  2. As políticas de Recusar são mais frágeis, pois o DynamoDB poderá introduzir novas funcionalidades de API no futuro que permitirão um padrão de acesso que você pretendia bloquear.

P: Como evito que os usuários adicionem dados inválidos à tabela?

Os controles disponíveis do FGAC podem determinar quais itens podem ser alterados ou lidos e quais atributos podem ser alterados ou lidos. Os usuários podem adicionar novos itens sem esses atributos bloqueados e alterar o valor de qualquer atributo que é modificável.

P: Posso conceder acesso a vários atributos sem relacionar todos eles?

A linguagem de políticas do IAM oferece suporte a um conjunto completo de operações de comparação, incluindo StringLike, StringNotLike e muitas outras. Por exemplo, o fragmento de política a seguir corresponde a todos os atributos que começam com "public_":

P: Como crio uma política adequada?

Recomendamos que você use o DynamoDB Policy Generator do console do DynamoDB. Você também pode comparar sua política às listadas no Amazon DynamoDB Developer Guide para ter certeza de seguir um padrão recomendado. Você pode publicar políticas nos fóruns da AWS para obter opiniões da comunidade do DynamoDB.

P: Posso conceder acesso de acordo com um código de usuário canônico em vez de em códigos separados de usuário com base no provedor de identidade com que fizeram login?

Não, a não ser que você execute uma "máquina de venda de tokens". Se um usuário recuperar o acesso federado à sua função do IAM diretamente usando as credenciais do Facebook com STS, essas credenciais temporárias têm informações apenas sobre o login do usuário no Facebook e não do login do usuário no Amazon ou no Google. Se você quiser armazenar internamente um mapeamento desses logins para o seu próprio identificar estável, pode executar um serviço para o login do usuário e então chamar o STS e fornecer as credenciais com escopo ajustado para qualquer valor de chave de hash que você especificar como o código de usuário canônico.

P: Quais informações não podem ser ocultas dos chamadores usando o FGAC?

No momento, algumas informações sobre os itens na tabela não podem ser bloqueadas para o chamador:

  • Métricas da coleção de itens. O chamador pode solicitar a estimativa de número de itens e do tamanho em bytes da coleção de itens.
  • Taxa de transferência consumida. O chamador pode solicitar o detalhamento ou o resumo da taxa de transferência provisionada consumida pelas operações.
  • Casos de validação. Em alguns casos, o chamador pode saber da existência e do schema da chave primária de uma tabela, quando você não tinha intenção de oferecer esse acesso. Para evitar que isso aconteça, siga o princípio do menor privilégio e permita acesso apenas às tabelas e ações que você pretende que sejam acessadas.
  • Se você negar acesso a atributos específicos em vez de criar uma lista de permissão de acesso a atributos específicos, o chamador teoricamente poderá determinar os nomes dos atributos ocultos usando um alógica "permitir todos exceto por". Em vez disso, é mais seguro criar uma lista de permissão de acesso a atributos específicos.

P: O Amazon DynamoDB oferece suporte a permissões IAM?

Sim, o DynamoDB irá suportar permissões de nível de API por meio do serviço de integração da AWS Identity and Access Management (IAM).

Para mais informações sobre IAM, consulte:


P: Como serei cobrado pelo uso que eu fizer do Amazon DynamoDB?

Cada tabela do DynamoDB possui taxa de transferência de leitura e taxa de transferência de gravação provisionadas associadas a ela. A cobrança será efetuada por hora pela capacidade de taxa de transferência caso exceda o nível gratuito.

Observe que você será cobrado por hora, pela capacidade de taxa de transferência que você provisionar para sua tabela, enviando ou não solicitações para sua tabela. Caso queira fazer alterações na sua capacidade de taxa de transferência provisionada, você pode usar o AWS Management Console ou a API UpdateTable.

Além disso, o DynamoDB também cobra o valor de armazenamento de dados indexados, assim como as taxas cobradas por transferência de dados de Internet padrão

Para saber mais sobre os preços do DynamoDB, visite nossa página de definição de preços do DynamoDB.

P: Existem exemplos de definição de preço?

Veja um exemplo de como calcular os custos de taxa de transferência usando os preços da região Leste dos EUA (Norte da Virgínia). Para ver os preços das outras regiões, visite nossa página de definição de preços.

Se você criar uma tabela e solicitar 10 unidades de capacidade de gravação e 200 unidades de capacidade de leitura de taxa de transferência provisionada, será cobrado da seguinte forma:

USD 0,01 + (4 x USD 0,01) = USD 0,05 por hora

Se as necessidades de sua taxa de transferência mudarem e você aumentar sua solicitação de taxa de transferência reservada para 10.000 unidades de capacidade de gravação e 50.000 unidades de capacidade de leitura, sua cobrança será alterada para:

(1.000 x USD 0,01) + (1.000 x USD 0,01) = USD 20/hora

Para saber mais sobre os preços do DynamoDB, visite nossa página de descrição de preços do DynamoDB.

P: Os preços incluem impostos?

Exceto onde informado de outra forma, nossos preços não incluem impostos e taxas (inclusive ICMS e imposto sobre vendas) aplicáveis. Para clientes com endereço de cobrança no Japão, o uso da região Ásia-Pacífico (Tóquio) está sujeito ao imposto sobre consumo japonês. Saiba mais.

P: O que é taxa de transferência provisionada?

O Amazon DynamoDB lhe permite especificar a taxa de transferência de solicitações que você deseja que sua tabela alcance. Nos bastidores, o serviço controla o provisionamento de recursos para alcançar o valor da taxa de transferência de solicitações. Em vez de lhe perguntar sobre instâncias, hardware, memória e outros fatores que podem afetar seu valor de taxa de transferência, nós simplesmente solicitamos que você forneça o nível de taxa de transferência que deseja alcançar. Esse é o modelo de serviço de taxa de transferência provisionada.

O Amazon DynamoDB lhe permite especificar as necessidades de taxa de transferência em termos de unidades de capacidade de leitura e de capacidade de gravação para a sua tabela. Durante a criação de uma tabela, você especifica as necessidades de capacidade de gravação e leitura, e o Amazon DynamoDB particiona e reserva automaticamente a quantidade apropriada de recursos para atender às suas solicitações de taxa de transferência. Para decidir sobre os valores de taxa de transferência de gravação e leitura requeridos, considere o número de chamadas de API no plano de dados de leituras e gravações que você espera executar por segundo. Se em algum momento prever um crescimento de tráfego que possa vir a exceder a taxa de transferência provisionada, você pode simplesmente atualizar os valores da taxa de transferência provisionada por meio do AWS Management Console ou de APIs do Amazon DynamoDB. Também é possível reduzir o valor da taxa de transferência provisionada para uma tabela caso haja diminuição na demanda. O Amazon DynamoDB permanecerá disponível enquanto aumenta ou diminui o nível de escalabilidade da taxa de transferência.

P: Como a seleção de chave primária influencia a escalabilidade que posso alcançar?

Ao armazenar os dados, o Amazon DynamoDB divide uma tabela em várias partições e distribui os dados com base no elemento de chave de hash da chave primária. Enquanto aloca recursos de capacidade, o Amazon DynamoDB considera um padrão de acesso relativamente aleatório através de todas as chaves primárias. Você deve configurar o modelo de dados para que suas requisições resultem em uma distribuição praticamente uniforme de tráfego através das chaves primárias. Se uma tabela tem um número muito pequeno de elementos de chave de hash acessados de modo expressivo, mesmo um elemento de chave de hash específico usado de modo expressivo, o tráfego é concentrado em um pequeno número de particionamentos – potencialmente somente um particionamento. Se a carga de trabalho estiver expressivamente desigual, o que significa estar focada desproporcionalmente em um ou poucos particionamentos, as operações não alcançarão o nível total de taxa de transferência provisionada. Para obter o melhor resultado da taxa de transferência do Amazon DynamoDB, construa tabelas em que o elemento de chave de hash possua um grande número de valores diferentes, sendo os valores requisitados de modo bastante uniforme, tão aleatoriamente quanto possível. Um exemplo de uma boa chave primária é o CustomerID e se o aplicativo tiver muitos clientes e solicitações feitas para vários registros de clientes, ela tende a ser mais ou menos uniforme. Um exemplo de chave primária expressivamente assimétrica é “Nome da categoria do produto” onde certas categorias do produto são mais populares que outras.

P: O que é uma unidade de capacidade de gravação e leitura?

Como estimo quantas unidades de capacidade de leitura e escrita preciso para o meu aplicativo? Uma unidade de capacidade de escrita permite desempenhar uma escrita por segundo para itens de até 1 KB de tamanho. Da mesma forma, uma unidade de capacidade de leitura permite que você execute uma leitura fortemente consistente por segundo (ou duas leituras eventualmente consistentes por segundo) de itens com mais de 4 Kb de tamanho. Itens maiores exigirão uma capacidade maior. É possível calcular o número de unidades de uma leitura ou gravação desejada pela estimativa do número de leituras ou gravações que precisa fazer por segundo, e multiplicar pelo tamanho dos itens (arredondado para o KB mais próximo).

Unidades de capacidade requeridas para gravações = Número de itens gravados por segundo x tamanho do item (arredondado para o KB mais próximo)

Unidades de capacidade requeridas para leituras* = Número de itens lidos por segundo x tamanho do item (arredondado para o KB mais próximo)

* Caso você use leituras eventualmente consistentes terá duas vezes a taxa de transferências em termos de itens por segundo.

Se os itens tiverem menos que 1 KB de tamanho, então cada unidade de capacidade de leitura fornecerá 1 leitura/segundo da capacidade; e cada unidade de capacidade de gravação fornecerá 1 gravação/segundo de capacidade. Por exemplo, se os itens tiverem 512 bytes e sua necessidade de leitura for de 100 itens por segundo da tabela, será preciso fornecer 100 unidades de capacidade de leitura.

Se os itens tiverem mais que 1 KB de tamanho, você deverá calcular o número de unidades de capacidade de leitura e de capacidade de gravação necessárias. Por exemplo, se os itens tiverem 1,5 KB e sua necessidade de leitura for de 100 itens/segundo, será preciso fornecer 100 (leitura por segundo) x 2 (1,5 KB arredondados para o número inteiro mais próximo) = 200 unidades de capacidade de leitura.

Observe que o número necessário de unidades de capacidade de leitura é determinado pelo número de itens que são lidos por segundo, não pelo número de chamadas de API. Por exemplo, se sua necessidade de leitura for de 500 itens por segundo da tabela, e os itens tiverem 1 KB ou menos, serão necessárias 500 unidades de capacidade de leitura. Não importa se são feitas 500 chamadas de GetItem individuais ou 50 chamadas de BatchGetItem; cada uma retornará 10 itens.

P: Sempre poderei alcançar meu nível de taxa de transferência provisionada?

O Amazon DynamoDB considera um padrão de acesso relativamente aleatório através de todas as chaves primárias. Você deve configurar o modelo de dados para que suas solicitações resultem em uma distribuição praticamente uniforme de tráfego através das chaves primárias. Caso você tenha um padrão de acesso assimétrico ou irregular, pode ser que não consiga alcançar o nível de taxa de transferência provisionada.

Ao armazenar os dados, o Amazon DynamoDB divide uma tabela em várias partições e distribui os dados com base no elemento de chave de hash da chave primária. A taxa de transferência provisionada associada com a tabela é também dividida entre as partições; cada taxa de transferência de partição é gerenciada independentemente com base na cota designada para tanto. Não há compartilhamento da taxa de transferência entre as partições. Consequentemente, a tabela no Amazon DynamoDB é mais capaz de corresponder aos níveis de taxa de transferência provisionada se a carga de trabalho for distribuída bastante uniformemente por entre os valores de chave de hash. Ao distribuir valores de chave de hash por entre as solicitações, distribui-se as solicitações entre os particionamentos, o que ajuda a alcançar o nível de taxa de transferência provisionada por completo.

Caso você tenha um padrão de carga de trabalho irregular através das chaves primárias, e não consiga alcançar o nível de taxa de transferência provisionada, poderá satisfazer mais tarde suas necessidades de taxa de transferência ao aumentar o nível da taxa de transferência provisionada, o que lhe proporcionará mais taxa de transferência para cada particionamento. No entanto, recomendamos que considere modificar seu padrão de solicitação ou modelo de dados para que possa alcançar um padrão de acesso aleatório relativo através das chaves primárias.

P: O que é a taxa de transferência máxima que eu posso fornecer para uma tabela do DynamoDB específica?

O DynamoDB é projetado para escalonar infinitamente. Entretanto, caso você deseje ultrapassar taxas de transferência de 10.000 unidades de capacidade de gravação ou 10.000 unidades de capacidade de leitura em uma única tabela, você deve primeiro entrar em contato com a Amazon preenchendo este formulário on-line. Se você deseja provisionar mais que 20.000 unidades de capacidade de gravação ou 20.000 unidades de capacidade de leitura em uma mesma conta de assinatura, você deve primeiro entrar em contato conosco usando o formulário acima.

P: Qual é a taxa de transferência mínima que eu posso provisionar para uma tabela do DynamoDB específica?

A menor taxa de transferência provisionada que você pode solicitar é de 1 unidade de capacidade de gravação e 1 unidade de capacidade de leitura.

Isso está incluído no nível gratuito, que permite 5 unidades de capacidade de gravação e 10 unidades de capacidade de leitura. O nível gratuito aplica-se ao nível da conta, não ao nível da tabela. Em outras palavras, se você acrescentar a capacidade provisionada de todas as suas tabelas e se a capacidade total não for superior a 5 unidades de capacidade de gravação e 10 unidades de capacidade de leitura, então sua capacidade provisionada não se aplicará ao nível gratuito.

P: Há algum limite de quanto posso alterar minha taxa de transferência provisionada com uma única solicitação?

Sim. O Amazon DynamoDB permite que você altere seu nível de taxa de transferência provisionada em até 100% com uma única chamada de API UpdateTable. Se você deseja aumentar sua taxa de transferência em mais de 100%, é possível simplesmente chamar UpdateTable novamente.

Por exemplo, se sua tabela tiver 1.000 unidades de capacidade de gravação provisionada, não será possível atualizar sua tabela para 3.000 com uma única chamada de API, pois isso está acima da alteração máxima permitida para uma única operação UpdateTable. Para aumentar sua taxa de transferência de 1.000 para 3.000 unidades de capacidade de gravação, é só fazer uma chamada UpdateTable para primeiro dobrar sua taxa de transferência para 2.000 e, em seguida, chamar UpdateTable uma segunda vez para atingir o valor de 3.000 gravações/segundo.

P: Como serei cobrado pela taxa de transferência provisionada?

Toda tabela do Amazon DynamoDB possui um pré-provisionamento de recursos necessário para alcançar o valor da taxa de transferência solicitado. Você é cobrado pela hora de utilização enquanto sua tabela continuar com esses recursos. Para obter uma lista completa de preços com exemplos, consulte a página de definição de preços do DynamoDB.

P: Como posso alterar a taxa de transferência provisionada para uma tabela do DynamoDB existente?

Há duas maneiras de atualizar a taxa de transferência provisionada de uma tabela do Amazon DynamoDB. É possível fazer a alteração no console de gestão ou usar a chamada de API UpdateTable. Você pode alterar sua taxa de transferência em até 100% mediante uma única chamada API, como descrito em: "Há algum limite de quanto posso alterar minha taxa de transferência provisionada com uma única chamada de API?"

O Amazon DynamoDB permanecerá disponível enquanto o nível de sua taxa de transferência aumenta ou diminui.

P: Com que frequência posso alterar minha taxa de transferência provisionada?

Você pode aumentar sua taxa de transferência provisionada sempre que desejar. É possível diminuí-la duas vezes por dia. Um dia é definido de acordo com o fuso horário GMT. Por exemplo, se você reduzir a taxa de transferência provisionada para sua tabela duas vezes em 12 de dezembro, não terá permissão para reduzir novamente a taxa de transferência provisionada para a tabela antes das 12h01 GMT de 13 de dezembro.

Lembre-se de que você não pode alterar a taxa de transferência provisionada se sua tabela do Amazon DynamoDB ainda estiver processando a resposta à sua última solicitação para alterar a taxa de transferência provisionada. Use o console de gestão ou a API DescribeTables para verificar o status da sua tabela. Se o status for "CREATING", "DELETING" ou "UPDATING", você não poderá ajustar a taxa de transferência da tabela. Espere até que sua tabela apresente o status "ACTIVE" e tente novamente.

P: O nível de consistência afeta o valor da taxa de transferência?

Sim. Para uma determinada distribuição de recursos, o valor de leitura que uma tabela do Dynamo pode alcançar é diferente para leituras fortemente consistentes e eventualmente consistentes. Se você solicita "1.000 unidades de capacidade de leitura", o DynamoDB distribuirá recursos suficientes para alcançar 1.000 leituras fortemente consistentes por segundo de itens de até 1 KB. Caso deseje alcançar 1.000 leituras eventualmente consistentes de itens de até 1 KB, precisará de metade dessa capacidade, ou seja, 500 unidades de capacidade de leitura. Para obter mais orientações sobre a escolha de um valor apropriado de taxa de transferência, consulte nosso guia de taxa de transferência provisionada.

P: O tamanho do item afeta a taxa de transferência?

Sim. Para uma determinada distribuição de recursos, o valor de leitura que uma tabela do DynamoDB pode alcançar depende do tamanho de um item. Quando uma taxa de transferência provisionada que você gostaria de alcançar é especificada, o DynamoDB fornece os recursos pressupondo que os itens serão menores que 1 KB. Cada aumento maior que 1 KB irá aumentar linearmente os recursos necessários para alcançar o mesmo valor de taxa de transferência. Por exemplo, se você forneceu uma tabela do DynamoDB com 100 unidades de capacidade de gravação, que significa que ela pode suportar 100 gravações de 1 KB por segundo, ou 50 gravações de 2 KB por segundo, ou 25 gravações de 4 KB por segundo, e assim por diante. Para mais orientações sobre a escolha de um valor apropriado de taxa de transferência para sua tabela, consulte o guia de taxa de transferência provisionada.

P: O que acontece se o meu aplicativo executa mais leituras ou gravações do que a minha capacidade provisionada?

Se seu aplicativo executar mais leituras/segundo ou gravações/segundo do que sua capacidade de taxa de transferência provisionada da tabela permite, solicitações acima de sua capacidade de provisionamento serão suspensas e você receberá o código de erro 400. Por exemplo, se você solicitou 1.000 unidades de capacidade de gravação e tentar fazer 1.500 gravações/segundo de itens de 1 KB, o DynamoDB somente permitirá a análise de 1.000 gravações/segundo e você receberá o código de erro 400 em suas solicitações extras. Você deve usar o CloudWatch para controlar suas taxas de solicitações para garantir que sempre terá uma taxa de transferência provisionada suficiente para alcançar a taxa de solicitações de que precisa.

P: Como posso saber se eu estou excedendo minha capacidade de taxa de transferência provisionada?

O DynamoDB publica sua capacidade de taxa de transferência consumida como um indicador do CloudWatch. É possível definir um aviso para esse indicador, assim você será notificado(a) caso se aproxime da capacidade provisionada.

P: Quanto tempo o nível de taxa de transferência de uma tabela leva para ser alterado?

Geralmente, a redução de taxa de transferência levará entre alguns segundos e alguns minutos, enquanto o aumento de taxa de transferência leva normalmente entre alguns minutos e algumas horas.

É altamente recomendado que você não tente agendar um aumento na taxa de transferência para ocorrer praticamente ao mesmo tempo em que a taxa de transferência extra será necessária. Recomendamos o provisionamento da capacidade de taxa de transferência com antecedência suficiente para garantir que ela esteja disponível quando necessário.

P: O que é a capacidade reservada?

A capacidade reservada é um recurso de cobrança que permite obter descontos sobre a capacidade de taxa de transferência provisionada como compensação por:

  • Um único pagamento antecipado
  • Um compromisso de nível mínimo de utilização mensal durante a vigência do contrato.

A capacidade reservada se aplica a uma única região da AWS e pode ser comprada com vigência de 1 ou 3 anos. Cada tabela do DynamoDB tem sua própria capacidade de taxa de transferência provisionada. A capacidade de leitura ou gravação desejada para a tabela é especificada na sua criação ou alteração. Essa capacidade é o que determina a taxa de transferência de leitura e gravação que a tabela do DynamoDB pode utilizar. A capacidade reservada é um acordo de cobrança e não afeta diretamente o desempenho e a capacidade das tabelas do DynamoDB. Por exemplo, se você compra 5.000 unidades de capacidade de gravação de capacidade reservada, concorda em pagar por essa capacidade durante o acordo (1 ou 3 anos) em troca de um desconto no preço. P: Como compro capacidade reservada? Faça login no AWS Management Console, vá para a página do console do DynamoDB e clique em "Purchase Reserved Capacity". Será exibido um formulário que você pode preencher para comprar a Capacidade Reservada. Não deixe de selecionar a região da AWS na qual a capacidade reservada será utilizada. Aguarde até duas semanas para o processamento da solicitação de compra. Você será notificado por e-mail quando a solicitação de compra for processada.

P: Posso cancelar uma compra de capacidade reservada?

Não, você não pode cancelar a capacidade reservada e o pagamento único não é reembolsável. Você continuará a pagar por cada hora durante a vigência da capacidade reservada, independentemente da utilização.

P: Qual a menor quantidade de capacidade reservada que posso comprar?

A menor oferta de capacidade reservada é de 5.000 unidades de capacidade de gravação e 5.000 unidades de capacidade de leitura.

P: Posso comprar a capacidade reservada usando APIs?

Ainda não. Ofereceremos APIs e adicionaremos mais opções de capacidade reservada ao longo do tempo.

P: Quantas compras de capacidade reservada posso fazer?

No momento, cada conta da AWS pode fazer uma compra de capacidade reservada. Ampliaremos a nossa oferta de capacidade reservada no futuro para permitir mais compras de capacidade reservada por conta.

P: Posso mover a capacidade reservada de uma região para outra?

Não. A capacidade reservada está associada a uma única região.

P: Posso provisionar uma capacidade de taxa de transferência maior que a capacidade reservada?

Sim. Quando você compra a capacidade reservada, concorda com um nível mínimo de utilização e paga uma taxa com desconto por esse nível de utilização. Se você provisionar capacidade além desse nível mínimo, serão cobradas as taxas padrão para essa capacidade adicional.

P: Como utilizo a capacidade reservada?

A capacidade reservada é aplicada automaticamente à sua conta. Por exemplo, se você comprar uma capacidade reservada de 5.000 unidades de capacidade de gravação e provisionar 6.000, sua compra de capacidade reservada cobrirá automaticamente o custo de 5.000 unidades de capacidade de gravação e você pagará as taxas padrão pelas 1.000 unidades de capacidade de gravação restantes.

P: O que acontece se eu provisionar uma capacidade de taxa de transferência menor que a capacidade reservada?

Uma compra de capacidade reservada é um contrato para pagar por uma quantidade mínima de capacidade de taxa de transferência provisionada durante a vigência do contrato em troca do preço com desconto. Se você usar menos que a capacidade reservada, essa quantidade mínima de capacidade de taxa de transferência provisionada continuará a ser cobrada mensalmente.

P: Posso usar a capacidade reservada para várias tabelas do DynamoDB?

Sim. A capacidade reservada é aplicada à capacidade provisionada total dentro da região para a qual você comprou a capacidade reservada. Por exemplo, se você comprou 5.000 unidades de capacidade de gravação, pode aplicar essa capacidade a uma tabela a uma tabela com 5.000 unidades de capacidade de gravação, 100 tabelas com 50 unidades de capacidade de gravação ou 1.000 tabelas com 5 unidades de capacidade de gravação e assim por diante.