Índices secundários globais e índices secundários locais

A chave primária do DynamoDB define o único caminho de consulta eficiente em uma tabela. Se você precisar consultar itens por um atributo diferente — por exemplo, se quiser encontrar todos os pedidos de um ID de produto quando a chave de partição da tabela for CustomerId — terá de executar um Scan dispendioso sem um índice secundário.

Os índices secundários resolvem esse problema mantendo uma cópia separada dos dados, atualizada automaticamente e estruturada em torno de uma chave diferente. O DynamoDB oferece dois tipos: Global Secondary Indexes (GSI) e Local Secondary Indexes (LSI), cada um com diferentes vantagens e desvantagens.

Um Global Secondary Index permite definir uma chave de partição completamente diferente (e, opcionalmente, uma chave de ordenação) da tabela base. O GSI é realmente global: ele abrange todas as partições da tabela base. Você pode consultar um GSI para encontrar itens por qualquer atributo definido como chave de partição do GSI.

Os GSI têm sua própria taxa de transferência provisionada (ou herdam o modo sob demanda), independentemente da tabela base. Você pode criar até 20 GSI por tabela e adicionar ou excluir GSI a qualquer momento em uma tabela existente.

Um Local Secondary Index compartilha a mesma chave de partição da tabela base, mas usa uma chave de ordenação diferente. Os LSI são “locais” porque consultam apenas dentro de uma única partição (itens com a mesma chave de partição). Isso torna os LSI ideais para consultar os pedidos de um cliente específico, ordenados por atributos diferentes.

Os LSI devem ser definidos no momento da criação da tabela; não é possível adicioná-los ou removê-los posteriormente. Cada tabela pode ter até 5 LSI. Os LSI compartilham a capacidade provisionada da tabela base (sem taxa de transferência separada) e estão sujeitos ao limite de armazenamento de 10 GB por chave de partição, considerando a combinação dos dados da tabela base e dos LSI.

Veja uma comparação lado a lado para facilitar a preparação para o exame:

• Chave de partição: GSI pode ser diferente da tabela base; LSI deve corresponder à tabela base
• Chave de ordenação: ambas permitem uma chave de ordenação diferente da tabela base
• Quando é criada: GSI a qualquer momento; LSI somente durante a criação da tabela
• Throughput: GSI tem o seu próprio; LSI compartilha o throughput da tabela base
• Consistência: leituras de GSI têm apenas consistência eventual; leituras de LSI podem ter consistência forte
• Limites: até 20 GSIs; até 5 LSIs por tabela

Ao criar um índice, você escolhe quais atributos são projetados (copiados) para ele:

• KEYS_ONLY: somente a chave primária da tabela base e a chave do índice — é o menor índice, mas exige chamadas adicionais a GetItem para atributos que não são chaves
• INCLUDE: atributos de chave mais uma lista específica de atributos adicionais que você indicar — equilibra o tamanho e o padrão de acesso
• ALL: todos os atributos são projetados para o índice — é a opção mais flexível, mas tem maior custo de armazenamento e gravação

Escolha o tipo de projeção com base nos atributos de que suas consultas realmente precisam. Projetar atributos em excesso desperdiça WCUs a cada gravação; projetar atributos insuficientes exige chamadas adicionais a GetItem para buscar atributos que não estão no índice.

Consultar um GSI usa a mesma API Query, mas especifica o parâmetro --index-name. A consulta é executada usando o esquema de chaves do GSI, e não o da tabela base. As consultas a GSIs sempre têm consistência eventual — o GSI é atualizado de forma assíncrona após as gravações na tabela base, portanto há um breve atraso.

Se um item da tabela base não tiver o atributo de chave de partição do GSI, ele não será incluído no GSI (padrão de índice esparso). Essa é uma técnica poderosa para indexar somente um subconjunto de itens, como todos os pedidos com status PENDING quando a chave de partição do GSI é Status.

Um índice esparso aproveita o fato de que o DynamoDB só projeta itens em um GSI se eles tiverem um valor para a chave de partição do GSI. Ao definir a chave de partição do GSI com base em um atributo presente apenas em alguns itens, você cria um índice contendo somente esse subconjunto.

Exemplo: em uma tabela Orders, somente os pedidos não enviados têm um atributo PendingShipmentDate. Um GSI em PendingShipmentDate contém naturalmente apenas os pedidos não enviados, tornando-se uma forma altamente eficiente de consultar todos os pedidos pendentes sem verificar a tabela inteira.

A sobrecarga de GSI é uma técnica avançada de projeto de tabela única na qual você armazena diferentes tipos de entidade em uma tabela e usa um atributo genérico de chave do GSI (por exemplo, GSI1PK e GSI1SK), preenchido com padrões diferentes conforme o tipo do item. Isso fornece a cada tipo de entidade seu próprio caminho eficiente de consulta por meio de um único GSI.

Exemplo: para itens User, defina GSI1PK = 'COUNTRY#US' e GSI1SK = username; para itens Order, defina GSI1PK = 'STATUS#PENDING' e GSI1SK = orderDate. Consultar o GSI com o prefixo apropriado recupera o tipo de entidade desejado com eficiência.

A limitação de GSI ocorre de forma independente da tabela base. Se as WCUs provisionadas do GSI forem muito baixas, as gravações em itens projetados no GSI sofrerão limitação — mesmo que a tabela base tenha bastante capacidade. Monitore ConsumedWriteCapacityUnits e ThrottledRequests separadamente para cada GSI.

Um problema comum é provisionar o GSI com uma capacidade menor que a da tabela base e, depois, sofrer limitações quando um padrão de gravação aumenta repentinamente a taxa de gravação no GSI. Use o Auto Scaling nos GSIs ou escolha o modo sob demanda para evitar isso.

Orientações para decisão no exame SAA-C03:

• Você precisa consultar por um atributo completamente diferente → GSI
• Você precisa consultar dentro da mesma partição, mas com uma ordenação diferente, e sabe disso no momento da criação → LSI
• Você precisa de leituras fortemente consistentes em uma chave de ordenação alternativa → LSI (é a única opção, pois GSIs têm consistência eventual)
• Você tem dez ou mais padrões de consulta distintos → considere o projeto de tabela única com sobrecarga de GSI em vez de muitas tabelas separadas
• Você só precisa recuperar todos os itens para análise → reavalie se o DynamoDB é o banco de dados adequado

Você pode excluir um GSI a qualquer momento sem afetar a tabela base. Quando adiciona um novo GSI a uma tabela existente, o DynamoDB preenche o índice retroativamente de forma assíncrona, verificando a tabela base — isso pode levar de minutos a horas em tabelas grandes. Durante esse preenchimento, a tabela base permanece totalmente disponível para leituras e gravações.

Você pode monitorar o progresso do preenchimento no console ou por meio da API DescribeTable, verificando o campo IndexStatus do índice — ele será CREATING durante o preenchimento e ACTIVE quando concluído. Não consulte o GSI até que ele esteja ACTIVE.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu que: GSIs fornecem chaves de partição alternativas e podem ser adicionados a qualquer momento, LSIs compartilham a chave de partição base e devem ser definidos durante a criação, e os tipos de projeção controlam quais atributos são copiados para o índice. GSIs permitem padrões de índice esparso e de sobrecarga para oferecer flexibilidade avançada nas consultas. A seguir, exploraremos DynamoDB Streams e Global Tables.